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.
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:
- 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.)
- 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.
- 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.
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:
- 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.
- 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.