What would be the role of the manager?

First case: team and project manager

If he would handle the team and organize how the project is done, then indeed, without technical background, such manager might become a real treat which will lead to project failure. For this task, you need a person who understands:

• How developers are working and thinking by comparison to other jobs:

  1. What are their motivations?
  2. Why new features should be in production as soon as possible?
  3. Why comparing the raw productivity of two developers is so difficult?
  4. What are the real skills (such as communication skills) required from a developer?
  5. etc.

• How project is managed, especially:

  1. What is technical debt and why should it be taken in account?
  2. What are the techniques used for risk mitigation in software development projects?
  3. What iterative development brings to the project?
  4. Why tasks, such as refactoring, which don’t deliver immediately visible features are often much more important than shipping just another feature?
  5. Why it’s ok to go back and forth, instead of moving towards a goal?
  6. Why “solve this bug ASAP”/“deliver this feature ASAP” is crazy in practically every situation?
  7. What is the difference between a prototype and a solid production code?
  8. etc.

• What are the points which should be in focus from the beginning. While a team of developers with minimum experience will not forget to do unit tests or regular refactoring, they may be too focused on their own job.

  Sometimes, they forget about UX, security, deployment or end-user documentation, simply because it’s not their job, and when the product appears unusable, insecure, a nightmare for system administrators or lacking basic documentation, it’s often too late.

  It belongs to the manager to determine all the tasks required for a successful project, and to find the resources needed for their accomplishment. Having a bunch of programmers is not enough.

Second case: an intermediary between IT and non-technical world

If, instead, his task is to ensure good relations between the technical stuff and non-technical stakeholders, then a person who studied management, but has only light understanding of technical stuff may be ok.

Even then, try to pick a person who understands the specificity of software development and who have already a professional experience of several project failures: it would be a disaster to hire someone who would treat developers as “the guys who play with computers and are never able to get the stuff done”.

Let’s consider the points you included in your edit:

Create tasks for developers

What does that mean? Do you mean user stories? As is, there is no way to answer without knowing how those tasks are created in your team.

Monitor that our ticket workflow is respected

If it’s not, what would happen?

• The good answer is: “Retrospective will be used to identify what went wrong, in order to solve the previous issues and adjust the schedules to the speed of the team.” This requires technical background.

• The bad answer is: “The project manager would scream to team members, and tell that either they start programming faster, or somebody among them will be fired.” This doesn’t require any specific skill.

Warn developers is they cross estimated work time

See the previous points.

Manage weekly finance timesheets

No IT-related skills required here. But the manager should be aware of the specificity of software development, including the fact that it’s often impossible to predict how much a feature would cost to implement.

Help client and reply to his questions

Questions such as “When do we have our next meeting?” don’t require technical background. Questions such as “Is it possible to still use the synchronization mechanism we talked about the last week in a context of frequent connection loss?” requires to understand the inner workings of the project.

Set meetings between client and developers (internet meetings)

No technical skills needed here.

TL;DR: Alternative Solution – Rotate Project Lead

At my work we rotate project lead as each project comes up. Projects are just whatever set of work is needed to get to the next release, not tied to the actual codebase. The lead is responsible for all due diligence required to make the project a success. Not successfully developed, but successfully released and deployed. This means the lead has to collaborate with operations, customers, other stakeholders and programmers.

Why do this? I have found that this has a few benefits. For a lead engineer:

• once the business problem is well understood they are easily able to break down the tasks required to complete the project
• they can often provide alternatives that are cheaper to develop, but satisfy the business need
• they have a higher likelihood of knowing where the most risk lies (at least in development)
• there is less chance of misunderstanding among the development team, and even among the larger technical team
• for projects where there isn’t significant cross team dependence or co-development, the projects often can started earlier and complete quicker.
• familiarity with the codebase allows for more accurate planning and development, and understanding which things may cost a amount significant time which can then be communicated to the customer

I cannot emphasize how big a deal some of the points above have been for the various business I’ve worked at in the past that followed this model.

This places special requirements on the people that may become project lead.

• They need to be able to see the bigger picture, and be able to shift between the micro and macro.
• They need to be able to communicate with customers and other non-technical people.
• They need to work well with others.
• They need to understand how to break down a project in order to have other work on it to completion
• They need to think about what is required for deployment and running the software.
• They need to work with whomever will be running the software and collaborate with them throughout the project’s lifetime.

A good project manager will focus on the product you’re making – that it fulfils the requirements, and will provide direction on what those requirements will be. HE will also provide organisation to the team so it works productively on the things that matter.

Do you need such a guy? If so, a business-oriented chap is more likely to be used to this kind of role.

A senior programmer may not have enough experience or skill at managing customers, their requirements or organising the team.

This question is primary opinion based, and the following is just my opinion.

Shall we find a senior programmer from our programming field? Or we must find a regular guy (economics or management studies) who never coded in his life?

It’s a little alarming that you didn’t list previous project management experience as your first requirement, and that you need a project manager who has experience managing software projects.

What would happen if a project manager said “We need to hire a programmer, but our projects are always late. To solve that problem I’ll hire a project manager who knows a little about programming as our new programmer.”

Hire a project manager that specializes in managing software projects. Don’t hire someone who sees project management as a temporary step in their career.

Create tasks for developers
Monitor that our ticket workflow is respected
Warn developers is they cross estimated work time
Manage weekly finance timesheets
Help client and reply to his questions
Set meetings between client and developers (internet meetings)

There are two ways you can handle this. Have the software developers tell the project manager what his job is, or hire a project manager that will tell the software developers what their job is.

A technically knowledgeable manager will quickly gain the respect of fellow team members, but with that said. A non-technical manager who knows how to manage a team can gain the respect of the business owner.

It all depends on who the project manager is accountable too.

Large corporate companies can often afford to hire project managers that are highly technical and work closely with software teams. Smaller companies are more focused on the bottom line, and need project managers who manage costs first. Technical issues is why they hired the technical people.