Like many of my generation, I have what might be considered an unhealthy interest in personal technology. Yet, I find I am more fascinated by observing how tech companies are managed, the way work is accomplished, and studying how decisions are made, than the products these companies produce.
In higher education, work is often accomplished utilizing the same, well-established, formula. A decision is made that results in a task, individuals are assigned to the task, individuals meets to determine how to best complete the task – often several times – and finally produce a result intended to fulfill the criteria of the initial decision. In higher education, work – more often than not – begins with the idea and ends with the product.
Yet, much of the work in the technology industry is accomplished differently. Often, work begins with the product and ends with the idea or decision. There are a few interesting stories to illustrate this practice, but perhaps most notable is the origin story of the iPhone.
How does this apply to our work? I have noticed that professionals, particularly young professionals, are adept at identifying problems or needs within a department, yet often struggle addressing these needs. Perhaps they believe they lack the permission to address the need or recognize the divergence from the established practice for accomplishing work in our field. Yet, as a mid-level professional, I recognize that departmental needs have not gone unattended because one has failed to identify the issue. On the contrary, seldom are issues identified that have not yet been previously discovered. Priorities, workloads, dependency on related decisions, all can prevent identified issues from being resolved.
For example, a hall director may walk into your office and say, “I recognize we’ve had a number of roommate conflicts this year. I think we should have a roommate agreement for residents to complete at the beginning of the year to be proactive in addressing these issues.” Certainly, a roommate agreement is an established practice in housing departments. Likely, the problem is not lost on the supervisor, nor the solution. Yet, as previously stated, there may be reasons the department has yet to develop the solution. When the time arrives to implement one, we charge the task to a group of professionals. They meet, and after some time, develop a result.
However, how would the situation differ if the hall director walked into their supervisor’s office and stated, “I recognize we’ve had a number of roommate conflicts this year. I researched how other institutions address these issues using roommate agreements and worked with a colleague to create one that would best serve our communities.” I would content that the likelihood of the department adopting the presented roommate agreement (after providing appropriate feedback and suggested changes) is much higher than waiting to convene a group of individuals to create one.
Certainly, this will not always be the case. We may identify problems and develop solutions that ultimately will not be accepted. Yet, I contend that bringing a product, or a prototype, that solves the identified issue increases the possibility of the solution being adopted. I am not advocating that professionals neglect their responsibilities in favor of solving problems outside their purview. Nor, am I advocating that we accept solutions to issues simply because one is presented. Rather, I contend there is value in promoting this type of practice within our departments. Doing so, allows us to be innovative, robust, and promotes satisfaction among employees who believe they can positively contribute to their department’s growth and success.
The demands on higher education are increasing and it is important for us to establish practices that can effectively address identified issues soundly and quickly. I think it’s important that we encourage professionals not to simply be problem identifiers or problem solvers, but product developers.
You can connect with Matt on Twitter @mbloomingdale.