Every team needs some set of base operating principles. Or maybe a more frou-frou term is a charter or mission statement, but sometimes that gets lost in the management-speak and does not provide specific, actionable internal guidelines. In the past, I have called them “ground rules”, “guidelines”, “principles” and “behavior norms”. I have had team charters, but they were really intended for those outside looking in rather than those inside.
Employees need to know your expectations and non-negotiables. Maybe even the things you think are obvious. And they need to be written and available. If they are not written, they don’t exist.
As the IT manager, you need them too, if only to empower your performance reporting and reviews. These also form the basis for policies and procedures, and in the event you never get around to documenting policies and procedures, at least you will have this when some consultant, auditor, or efficiency expert asks you for them in front of your boss or customer. Furthermore, your team of technology professionals may never get around to reading your policies and procedures.
I would not recommend trying to capturing everything in a single mission statement, but I do recommend keeping it short, as in a couple pages. As mentioned above, your team may never get around to reading your policies and procedures. You can refer to an additional procedures document, but you must be able to sum up the essence here. For larger departments with multiple teams, the principles should be general in topic such that it can apply to the various functional responsibilities, and maybe individual team managers and leaders will customize or add specifics for their directs. Keep it short so you can occasionally read through it verbatim at staff meetings. In one management role, I used to reread every time we had someone join the team. I have seen some organizations display summary sentences of their operating principles on large poster board in the data center or office, or on laminated cards with a call list on one side and principles on the other.
Again, this can be invaluable for formal performance management. You can refer to it on every review form rather than having to explicitly write it out year after year. It can and should be a living document, but it needs to be stable and general enough that no one forgets and cannot be criticized at review time for constant permutations.
These principles should reflect the organization’s goals, the team’s functional responsibilities, and their most serious areas for improvement. For instance, they might include a set of expected behaviors to making changes to Production, adherence to a project management methodology, or list the communications plan.
It’s always prudent to pull in the company or organizational principles or values as well. For example, one company had a published value referencing they expected employees “to understand and work within our system, and who do what they say they will do”. The particular team I inherited had a problem with missing dates and veering off from standard procedures, so this provided a lead-in for a principle for keeping commitments. A statutory requirement to ensure enterprise “infrastructure is stable, secure and well-governed” was morphed into an operating principle to strive for minimal defects and rework and demand following a particular design methodology for a team with quality issues. A public company’s compliance responsibilities provided the foundation for strict adherence to change management and documentation.
Finally, the document should be given some authority, such as explicitly stating that this is expected behavior and will be included in HR performance objectives.