Project leadership of engineering team

Question

A team of engineers (software in this case) needs to be lead. Leadership can involve:

• Architect - Leads "design in the large" issues, such as what components to use
• Lead engineer - A peer leader, writes code while leading the team
• Project manager - Goal is to increase everyone else's productivity; focuses on who's doing what, bottlenecks, tasks, schedule, expectations
• Product owner - The voice of the customer, the market, the product

All of those roles contribute a lot. But, for a team of say 6 engineers, 4 leaders doesn't really make sense. And splitting leaders among multiple projects doesn't work well either.

So, given that a team is big enough to need leadership, how do you do it?

---

UPDATE: In response to the requests for clarification:

This is a small, growing company, with only 1 engineering team. It's not large enough for a matrix organization. Until now, it's been only 2 (later 3) engineers, who are also the business managers, owners, entrepreneurs, etc. Now that it's moving to a engineering team distinct from business management and ownership, it's clear that the team needs leadership. The question is as much about hiring (what type of role should we hire for) as it is about structure (how should authority and responsibility be structured).

In other places, I've seen teams where everyone was supposed to have these roles, which meant that no one had them. There a plenty of competent engineers which can carry out tasks, but can't architect, or manage a project, or understand the customer's needs. So there's a real need to make sure these roles are filled.

Answer 1

This answer depends a bit on your culture. A matrix structure is not uncommon in the US. With this option, the engineers would report to one leader for their technical issues, perhaps the Architect or the Lead engineer. However, for non-technical issues, the PM would provide the leadership necessary. This matrix structure allows workers to get what they need from those who are best able to provide it while still providing a formality to the structure.

In some countries, for example in France, workers do not normally easily accept the idea of having two bosses. For this reason, the matrix structure is extremely rare in those countries.

If you are using a matrix structure, you would not have one full time leader but rather two part-time leaders. The leaders being 'part time leaders' can also help with morale since those people will also be doing 'real work' along with the engineers.

Answer 2

TL:DR In your senario use a Lead Engineer who is knowledgeable about PM techniques as well as technical stuff.

Detailed Response There are many shades and variations, of course, and there is no real right answer to this. But I believe you are mistaken in some of your basic tenets. If you are talking about Project Leadership, where the project is software delivery, then only two of your roles should be considered for that leadership; Project Manager and Lead Engineer.

An Architect is not a leader of a software delivery team, they are a member of it with deliverables of their own (the architectural vision and design etc.)

A Product Owner (unless you are talking Agile here, in which case I am not sure of my position) is not a leader of a software delivery team, they feed requirements into the team on behalf of the user base and facilitate testing the output on behalf of the user base.

So in terms of leadership you should (massive generalisation) consider only the PM and the TL from your list.

For a small team, such as you outline, I would say the Technical Lead (Lead Engineer) should step up to the project leadership role, but only on the basis they understand that technical team leadership is NOT the same as project management (I'll return to this).

A pure Project Manager could be used in this scenario, but unless they are technical they will not be able to facilitate technical decision making and adjudication. Additionally they may be overwhelmed by technical detail and become less effective.

The problem is that Project Management requires different things than technical/engineering lead and you highlighted some of them above. But one of the key differences in this scenario is that the PM looks at the project delivery as a whole, not just the coding and development activities. So they would plan and facilitate testing, user workshops and managment of expectation, reporting to senior stakeholders on overall project progress, risks and issues management which can easily have nothing to do with engineering, and many more things besides. So your Lead Engineer would need to be PM savvy, or your PM would need to be somewhat technical, but even in the latter it is probably wise to include a technical lead in the team (perhaps not of the status Lead (or Chief is often used) Engineer as that role puts them on a par with the PM and therefore the project has two bosses).

You also have to bear in mind that coders/developers/technical engineers often do not take well to project management ("it'll be done when it's done") and that is where you really need a technical interface between the PM and the developers.

Answer 3

If I understand your question correctly, something that will help is drawing a distinction between project leadership and team leadership.

Project leadership - that is, leadership on issues related to the project work itself - can be pretty easily shared and you can get a lot of value out of collaborative leadership. The most success I've had (and seen in other teams) is to have different people be the final say on different areas - PM is your final word on process, PO on decisions about features and functionality, architect of software design, etc. Though they are the final say, everyone can weigh in. This usually keeps everyone invested and engaged, but you have a final say once the conversation is just spinning its wheels and no longer adding more value.

By team leadership, I mean the people who provide leadership on issues of team members directly. This would include things like unsatisfactory performance, career coaching, etc. In groups that are too small to have a dedicated manager, I've seen project managers share this role well. POs have too much at stake in deliver, so when they make demands of the team, it's self-serving. It can work to have a PO lead the team, but I think PM goes better. Having a team member do it is very difficult because he's too far in the weeds. That's not to say other people haven't made it work, but it's not what I'd recommend.

I hope that helps. Good question!

Answer 4

Forget about "leadership" and think about "responsibilities". "Who is responsible for what" is a much more important and correct question that "who is leading us?"

Your architect has to be responsible for technical decisions, and his word should be final. Your product owner will say how the product should look like, and his word is final, etc. Such an attitude will create much healthier environment than the one where people fight for "leadership".