As I have been considering various changes in my approach to management, leadership, and IT in higher ed, I am reminded of the importance of accountability. This is one of the most important parts of a successful team – it is part of the foundation upon which productivity and teamwork rests. In fact, it is part of a critically important cycle that is self-reinforcing – each phase of the cycle helps strengthen the continuation of that process. Accountability begets ownership. Ownership leads to a sense of responsibility. Feeling responsible results in a greater understanding of accountability. And the cycle continues.
Accountability must be pervasive, as well. It cannot be just to one’s supervisor or manager that one is accountable for his or her activities and performance. Peers must feel that they are part of the success of each of their colleagues and the team in general. Conversely, not only should managers be able to hold staff accountable, but peers should have the ability to “call out” those that are not helping meet overall expectations.
The thing about accountability as a departmental, top-bottom, bottom-top, side-side trait is that nothing is explicitly confrontational. Even the most severe conversation becomes about team and goals, rather than personal slight. Instead of “you are messing up my ability to get my job done,” one can say “we must rely on each other to get this project done to achieve a common, team goal.” I realize, of course, that we do not live in a utopia and that the former statement will still occur even in the most collaborative of environments now and then. The point is that co-dependency can become the foundation for discussion in a system that relies on accountability and shared ownership.
The question, therefore, is how to build what I call a “platform” for accountability. Much in the way that Windows or Facebook is a platform for development of software, accountability can be the foundation upon which projects and communication is constructed.
In an ideal world, an accountability platform can be built through some innate understanding and appreciation for project ownership and responsibility to help peers. That’s the “easy” scenario. But most situations are not “easy” and most teams are not operating with a zen-like level of shared ownership, with conversations about performance and co-dependency that are always warm and fuzzy. Sometimes baselines need to be set, and sometimes in ways that may seem rigid or even harsh. No one said the life of a manager is easy, though.
In a (somewhat) dysfunctional team scenario, nothing beats simply bringing everyone together and just talking through expectations. At some point individual meetings just won’t cut it. At the same time, it’s important not to “surprise” everyone with anything close to a sea-change, so letting people know the less confrontational parts isn’t a bad idea.
My personal plan is to approach the meeting first with laying the foundation of teamwork, clarifying my own role (removing myself as a go-between in the department), setting explicit expectations for each team member (establishing at least personal responsibility & ownership), connecting those expectations with other members (co-dependency), then establishing general expectations about communication, ownership, and accountability.
- My role –
outsidea peer member of the organization
The goal here is not to actually remove myself from the organization. If one pictures some diagram where each staff is a point in a hexagon (or whatever shape is appropriate for your group – dodecahedrons are welcome, though you might want to consider your org chart), I would still be in the middle. However, rather than communication lines occasionally being routed through me, all will take place from point to point (or point to points). I would not be a middle-man (though of course there would be connections to me – it’s not like I will stop talking to staff).
I would, however, exist outside of the framework, to be a connection with the school and university at large, enabling and facilitating the group and our goals. I would become a 7th point on our polygon. I would have significantly different responsibilities just because of the nature of my job but I’m not outside, I’m not above, etc. We all rely on each other.
- Setting explicit expectations (personal responsibility & ownership)
This is inline with many traditional meetings. Person A, I need this or that. Person B, your role is to provide this information, etc. However, it is important that everyone get some significant responsibility. This empowers and challenges each person. It also says that everyone must contribute. Make it clear that they must own the project.
- Connect the projects (co-dependency, team-based thinking)
Almost all tasks need to involve at least one other person. If you have sub-teams (say, your support team that handles help desk and classroom support) then make sure to keep cohesion there but also connect their efforts with another group or individual. This connection should still be a bit lop-sided – why give an explicit responsibility to establish ownership, then dilute that sense by saying “but you’re all equally responsible?” My goal is to stress that projects rely on others to be successful, and that there must be coordination and communication. On some projects, I will make accountability to me a shared issue. Person A is responsible for a deliverable and for working with Person B. Both are accountable for ultimate success (because success is possibly only with cooperation).
- Establish expectations (the unfortunate iron fist)
At the end of the day, it still has to be clear that the staff – working together, collaborating, being accountable to each other, etc – is still ultimately accountable to me, the manager. I protect them from the “outside world” but they have to back me up with their performance. Most importantly, when I establish that they are accountable for all these things, which are, in turn, vital to overall success, I must tie that into performance-based rewards. Unfortunately, the structure of the university is such that I can really only tie it into performance-based punishments. Nothing too severe, but the message must be clear: if we fail to meet a goal, and success was based on cooperation, then job expectations have not been met. The group (whole team, subset, etc) has failed to do its job.