Please go to the plugin admin page to Paste your ad code OR Suppress this ad slot.
This article on Technology and the College Generation from the New York Times didn’t surprise me. I have two teenagers and I use other forms for digital and social media to communicate. I can see the preferences towards texting and Twitter.
But I couldn’t help but think about how the business world uses email as a primary communication medium. I think it’s in the best interest of students to use email while in college as a way to prepare them for what they will see every day with an employer.
Email is a challenge to manage for many people. The challenges include:
Managing the volume of messages and time management
Writing effective messages that are clear and concise
Practicing common courtesy
But we must all learn and develop skills to battle these challenges.
Email is slower only by choice of usage patterns. The speed at which we can read a message is only as fast as the frequency at which we check our inbox. It’s no different than checking a Twitter or Facebook stream.
I would argue that email is a more effective communication method because the message is delivered directly to a personal inbox. It’s not in a global stream of messages like some social media sites. That only increases the chance a message will be missed.
Please go to the plugin admin page to Paste your ad code OR Suppress this ad slot.
What’s the purpose of a job description?
When a job is posted by a company there is a job description posted with the job. The description gives prospective employees a chance to see if their skills and experience match the qualifications the employer is expecting. In the hiring process, the job description is a functional document. It serves a purpose within the hiring event to bring an individual and an organization into a relationship.
But our job description changes over time.
As an employee acquires institutional knowledge of the company processes, systems, and clients the boundaries of the original job description start to blur. Typically an employee takes on new responsibilities as they complete project work, onboard new clients, or launch new technology solutions.
Employees also may receive new assignments through leadership changes or even receive assignments to work on projects and systems that didn’t exist when they were hired. For some employees the changes in responsibilities are subtle while for others more dramatic.
Some employees move into job responsibilities that didn’t exist anywhere when they were hired. When I left my previous employer I had responsibilities for internet analytics, digital marketing, internet advertising, and search engine optimization. None of these functions existed in the organization when I was hired.
How do we update our job description to match our current job function?
I thought about this question this week. My first thought was to periodically update the job description document that was used at the time of the original hire. But is this necessary and does it provide value? Depending on the amount of changes, updating the official document could change the classification of the job in the HR system. That triggers compensation reviews and job classifications. If the current job duties of the employee are dramatically different than their original job duties then I think this type of approach is warranted to be fair to the employee and to provide some documentation should the position need to be backfilled.
Another way to approach this is to look at the one-on-one meetings and the annual review between the manager and the employee. This is the time when a manager sets the expectations for the employee’s job duties and results. That provides the same function as the job description document. While the one-on-one meetings may be more informal and verbal in nature, the annual review tends to be more formal and is a good place to find out about the job description for an employee. We don’t think about the annual review document as a job description document. But the performance of the employee is evaluated against a set of standards and behaviors that comprise their job description.
Every year business teams go through planning and budgeting for the upcoming year. It’s a time consuming process. Middle and upper management work and rework presentations to present to executive management possibly board members. Budgets are submitted, then slashed, then reworked, and submitted again. Hours upon hours of work.
and then……….business happens.
New clients are signed that need to be on-boarded. Expected sales fall through or don’t materialize. Competitors upgrade their offering and drop their prices. Technology advances in a new direction.
Suddenly all that planning seems like a distant memory. Is anyone looking at the business objectives and roadmap that was planned for the current year nine months ago? My experience is that the plans are often forgotten and overruled by the tactical maneuvers of the current day.
Let’s not over complicate the matter.
Strategic plans are well intentioned. We have to plan to reach a goal or as the saying goes, “If you aim at nothing, you’ll hit it every time.” One way to help soften the risk of changing course due to changing market conditions is to plan smaller for a reduced time horizon. Instead of trying to plan for 12 months of work 15-18 months in advance, try planning six months of work nine months in advance. Don’t set 10 strategic goals, instead set 3-4 strategic goals and so that the organization can begin at the start of the measurement period.
It’s a similar concept to sprints in an agile development methodology for software development. Why not setup sprints for business objectives. Then remain more nimble to change as needed to match market conditions.
For technology teams one bit of advice is to first see the direction of the business (sales, marketing operations) and then align to help support those goals. In this way the plan will represent the core foundation (operations) of the business as well as the growth area (sales).
The first value statement in the Agile Manifesto is “Individuals and interactions over processes and tools”. Mike McLaughlin, of Version One, questions the role and influence the growing agile tool set has on individuals and interactions. McLaughlin states that the capability of Agile based software tools adds scalability and efficiencies, but that this does not remove the need for team members to interact with each other. His point is that we need to stick to the original intent of the manifesto language. Focus on the interactions, not the process.
It pulls like gravity.
It is human nature to gravitate toward stricter process and away from individuals and interactions. Organizations want to be lean to contain costs. Organizations want processes to provide consistent and efficient deliverables. These forces pull organizations toward larger processes and push employees away from the importance of the human interaction.
In my experience, the downside of a process is that it tends to become the goal of many who follow it. I’ve seen employees feel like they have accomplished their goal simply because they followed the 10 step process and populated the fields on a form. Usually when people reach this point they stop thinking about the people and interactions on the other side of the process.
Recently, a co-worker shared with me that she went to an in-network doctor for a procedure. The doctor chose to use a second medical provider for a part of the medical services. When the insurance company received the claim, they said the second medical provider was out of network, so the insurance company charged a different amount for their services. They penalized the insured as if it was the choice of the insured as to what secondary service the primary doctor chose to use. The process in this case missed the mark of the original intent. But it took over one year of appeals to get a reversal of course from the insurance policy.
A user story.
I recently wrote a project charter to frame-up an upcoming project. I chose a traditional project charter template because the original request for the project work was vague enough that it included a large number of possible outcomes. So I wanted a document format that could aid me with getting clarification for the project goals and better define the boundaries of the project project. To compile the charter I had to interview several business stakeholders to learn about program rules, pricing rules, and system constraints.
I used the project charter as a basis to then move into agile user stories. Now, I’ll be honest. I have not used the agile user story approach previously for requirements gathering. I have created use-cases in the past and user story follows a similar type of approach. But true to the agile manifesto, the user stories put less emphasis on a grand template and more emphasis on a conversation. I like the user story approach because it is setup to get requirement information from a project stakeholder through the use of everyday language. “As a , I want , so that . This type of approach encourages user interaction. It encourages natural dialogue to document requirements.
The result of interactions.
At the end of the user stories, I had a document that showed how the people involved in the project would interact and use a system and what they expected to get from it. To get there I had to interview and interact. Dare I say that’s a good process to follow for software development? 😉
But seriously, I think it steers discussion towards the benefits of the project work and away from the fields in a form. There is a structure to the user story template. But the structure is almost invisible because it adheres to natural language. I wasn’t even aware of the form structure while I conversed with the business stakeholder to gather input. At the end of our discussion, I had a user story. I had an artifact that could be used to begin design and coding. I had experienced the value of the first value statement in the Agile Manifesto.