Is discussion of models for hiring, promoting, and reviewing developers on-topic discussion?

Question

Background

tl;dr question is at the bottom

I am currently working as a middle manager for a mid-market manufacturing company that has an IT department consisting of:

• 6 developers (one lead, two senior, three junior). All of these developers are essentially working under me in a matrix managed environment. I would qualify as a 7th developer since I would likely contribute as well
• 2 specialized ERP developers
• 2 junior IT Business Analysts
• 1 specialized technical manager leading our ecommerce efforts
• 1 senior DevOps engineer who works closely with development
• A network and systems team ( 5 or 6 people? ) that runs separate from development except in small crossover areas like level 3 production support
• A team of 6 developer consultants working under the eCommerce Tech Lead
• A team 2-4 developer consultants possibly working on tangential projects

I moved up in the department from junior, senior, lead, and now I'm currently a principal engineer / software engineering manager ( my title is technically different but that is my job ). I have a very deep technical background but I believe I'm very strong at communicating and selling ideas, and making pragmatic decision with low budgets.

The Issue

My department doesn't run as efficiently or effectively as it should. This concern has been voice by my lead engineer, lead DevOps engineer, the eCommerce lead, and others. They feel the department lacks structure and they feel like too many people are off doing too many things. I share this belief and I feel like I see a blueprint in other companies and I see where our current personnel fit into this blueprint.

We currently use a tool to track sprints, stories, tasks, bugs, etc but our BA's don't have a strong conceptual grasp of what these concepts actual mean, and the business has no visibility into this. No story points are assigned to anything and no one tracks their time. I believe there is no adoption because the tool we use is a bloated legacy desktop application that lacks visibility and is just not convenient to use ( and doesn't integrate with any of our other tools )

We do whiteboard hiring where we run a technical whiteboard interview, a personal interview, then make a decision. The decision isn't very scientific, and our review process doesn't, in my opinion, support growth. You can continuously score 3 out of 5 in all review categories and stay employed in your current position forever.

Proposal

I have a proposal that outlines a tried and true model for making our department more effective which includes

• Some modifications to our current tooling
• Some professional development for certain employees
• Some rearrangement of job duties
• A more aggressive grow or go plan

Question

Would Software Engineering Stack Exchange be a good place to outline this topic in more detail. Basically a RFC ( request for comments )?

Answer 1

This site is about software engineering the topic, not programmers the persons.

A small subset of your questions may be on topic here, in particular regarding development processes and tooling. Software engineering includes some project management topics as well.

However, other parts of your questions are clearly out of scope. For example, hiring, personal development, and job duties are about management, not software engineering. A question does not become on topic because it has something to do with programmers; it must actually be about software engineering.

When asking a question that's more about softer issues, it can be hard to present that question in a way that's clearly not too broad and not opinion-based. Just posting a proposal and asking for feedback is a good start for a discussion, but it's not really an answerable question. Instead, try fitting your questions into one of these question types:

• Factual questions about development processes, e.g. “How do we plan a sprint in Scrum when a team member will go on vacation halfway through the sprint?”

• Questions that propose a clear solvable software engineering problem. It's a good idea to include your attempts at solving the problem, and to explain why they don't work. For example: “How can I coordinate multiple Scrum teams to develop a large feature together? We tried a Scrum of Scrums, but integrating the work from each team proved difficult.” This might give rise to completely different answers ranging from “appoint someone as an architect” to “do you have some time to talk about our lord and savior, microservices?”.

Note that your problem “My department doesn't run as efficiently or effectively as it should” isn't a software engineering problem. It is a symptom. There may be software engineering problems when you dig deeper, but that's not necessarily a given. For all I know, the real problem might be that upper management isn't communicating a clear vision for the company, or that the lighting in your office is bad.