Is it a good idea to talk about consequences in a meeting about dev processes?

Question

Not sure if this is the right forum for this question. Let me know if there is any other better place and I will post it there.

Here is what happened at work. Dev architect came up with new guidelines about coding practices, patterns etc. She presented it to the team. It's noteworthy that most of the team members are seasoned developers. She then also presented the process in case someone doesn't follow those guidelines which includes escalating issue to appropriate manager who will take corrective action.

I don't have any issue taking appropriate action(s) if someone is not following defined guidelines but this should happen on individual basis. My view is that one should set the guidelines so everyone in the team knows very well which are the expectations. But I don't see any need of going into details of consequences if some individuals "may" not follow those. I am very upset about why she went into details of consequences when most of team members follow all the processes. Not only its offensive to me but also disrespectful. I reported my concerns to the development director and manager but they didn't do anything about it. They even didn't respond to my email on this topic. Is my way of thinking out of reality Or am I too sensitive?

Answer 1

Within the bounds of project management, it is not generally good practices to bring out the stick with the carrot. Even when not using agile, project teams are expected to be professional adults who know how to get their job done.

Listing punitive consequences, as part of an opening design discussion, speaks of unprofessionalism. It also tells me the organization is unlikely to be using any of the progressive development techniques like Agile and Lean.

If someone I was mentoring was seeing this as a trend in their organization, I'd be advising them to look for a new job.

Answer 2

Poor interpersonal skills, likely driven by insecurity for that person in that role. There are a time and place for such language but it should be minimally used, only for exceptional circumstances and after other interventions have failed and when you are positive the people are broken and not the processes, tools, and other environmental drivers of poor performance.

It is also unlikely that you expressing your views to a person like this would have any impact, unless you have an existing strong, trusting relationship. The insecurity drivers for this person would cause him or her to be very defensive of you and then likely label you as the "enemy."

If I were in this role, I would do be my best to block and tackle this person away from the rest of the team, i.e., build motivation and encouragement in other venues and get the work done. It can feel like swimming against the tides, however. And, at some stage, looking for greener pastures is always an alternative.

Answer 3

Policies

You don't provide sufficient business context here. Policies, as a general rule, should be clear not only about expectations, but also about consequences. For example, any sensible HR policy that talks about core hours might say something like:

Employees are expected to be present during core hours from 10:00am - 4:00pm unless excused. A pattern of unauthorized absences can result in disciplinary action up to and including...

A policy with no teeth is a guideline. So, if a development policy with official backing is being communicated, it is likely to have an "or else" statement in there somewhere.

Agility and Collaboration

Your post isn't tagged with agile or any other context that would imply that top-down policies are inappropriate. Even so, an architect is rarely the line manager for a group of senior developers. As such, it's probably not appropriate for a engineering or architect level person to be making "or else" statements unless they've been directed to do so by senior management. Whether or not that's the case isn't clearly articulated in your post.

Digging Deeper

There may very well be a need for this command-and-control style of communication at your job. Without making personal assumptions about you as a person, when a team member says something like:

I am very upset...Not only its offensive to me but also disrespectful. I reported my concerns to the development director and manager but they didn't do anything about it.

Your statements suggest a number of things, including:

1. The level of emotional maturity and business experience of the person making this statement may be lower than it should be. While I respect your feelings, getting deeply offended at something that happens often enough to be typical in a corporate setting isn't a sign of career or personal maturity. (Note: I make this as an observation based on what you posted, not as a personal criticism. Take it as the observation it's meant to be.)
2. Raising concerns to management is often a legitimate thing to do, but their non-reaction tells you that they either support the architect's statements (in which case the architect was articulating a policy that management fully supports) or that they think you're overreacting.
3. It's also possible that you approached the conversation with your management team with an inappropriate emotional pitch, rather than a genuine wish to understand the context and purpose of the architect's communications. Complaints, anger, or "freaking out" rarely get treated as the opening to a constructive dialog.

Regardless of the underlying reasons, you should consider your options as outlined below.

Options

From a pragmatic perspective, the analysis of the current situation may help with understanding, but it's unlikely to significantly change what you can do about it. In all cases, you have two primary choices now:

1. If it's possible you're overreacting, and if the "or else" is unlikely to matter to a team that's doing all the right things anyway, then just let it go. Tilting at windmills is not a career-enhancing skill for most people.
2. If the real issue is that the development team is untrusted, and the organization has a command-and-control orientation rather than an interest in developing agile, self-directed teams, then you can work within the system to provide guidance on how to improve productivity through agile principles, organizational trust, and team empowerment.

If you find yourself unable to do either of those things, then the environment is probably a poor fit for you. Whether the problem is the organization or you is irrelevant; you will not do well in an organization that is a poor cultural fit for you, regardless of the reasons. If that's the case, dust off your resume and start looking for a new role.