Midwest IT Survival

Did you actually dance at your first school dance?

Jurgen Appelo recently posted his slides from the Scrum Gathering in Orlando entitled “The Dolt’s Guide To Self-Organization”.  I didn’t attend the conference, but in flipping through the slide deck, I was impressed by how much the concept of “self organizing teams” is a much better way to view the creation of a “Strong Team” as I tried to outline in a previous blog post .

I tried to capture in that previous post of mine a “hands off-ish” management style that fosters team members to step up and gravitate towards work they are interested in with the manager or team lead ensuring all the prioritized tasks needed are being handled by someone versus a more structured or top down task assignment approach.  Jurgen takes a different slant on a similar management style.  He starts with making the case that nature itself is self organizing rather than marching forward under the direction of a leader.  To further highlight this perspective, consider your first school dance or formal social gathering you attended.  Without activities directed by the school leadership, children tended to naturally separate into gender aligned groups.  Boys would be on one side of the gymnasium with girls on the other.  Then, within the gender groups, sub groups would form to further self organize along the common interests of sports, video games, comic books or other like enthusiasts.

In his presentation, Appelo suggests that “management” is not a direct natural extension of self organization, but exists none the less as a necessity.  Continuing the analogy above, the school dance needs chaperones.  How the chaperones interact or “manage” the students directly relates to how much fun the students have at the dance.  Mapping to managing an IT team or organization, how much micro versus macro management occurs relates to how much engagement and over all “value” is produced by the team or organization.  A high degree of micromanagement results in a low level of empowerment and thus a lower “value” produced by the team as a whole.  Flipping back to the School dance, if the chaperones are directing each student on what to do when on a seemingly constant basis, the kids in attendance are going to derive less fun or “value” from attending the dance.  Where as, if the chaperones are engaged in the dance event but allow the attendees the ability to interact on their own terms and only stepping in when a situation is trending negative (kids harassing or taunting others, kids on the verge of breaking out into a fight, etc.), the kids are in a better position to enjoy the dance.  The manger that is trying to constantly direct the team on a granular basis is going to reflect the over controlling chaperones at a school dance.  To sum up this notion of self-organization and how it fosters the empowerment to value equation, I discovered this quote from Majlinda Priku:

“People who actively participate in the workplace see greater skill development, and gain a greater understanding of which techniques are effective and which ones are not. They also have a greater opportunity to come up with creative solutions to problems, and novel ways to improve performance. The power to utilize their creativity and knowledge leads to expertise. People who are able to independently evaluate and implement projects have a sense of ownership that makes them committed to the project’s success.”  – Majlinda Priku, June 1, 2009,  http://www.articlesbase.com/leadership-articles/employee-empowerment-947535.html

Okay, so empowering employees through delegation to have more latitude to implement solutions to assignments sounds great, so how do you measure the level of empowerment and delegation currently in place within your team today to see where you stand?

Appelo has come up with an interesting way to represent this measurement as a sliding scale on slide 58:

Manager with authority in empowerment

Tell: make decision as the manager

Sell: convince people about decision

Consult: get input from team before decision

Join: make decision together with team

Advise: influence decision made by the team

Confirm: ask feedback after decision by team

Delegate: no influence, let team work it out

Employees with authority in empowerment

With “Tell” being the manager having the authority with little employee empowerment and “Delegate” being the employees having more authority and considerable empowerment.

I find this scalar approach to be extremely helpful as a way to reflect on recent decisions to measure the level of empowerment in place.  As an example, when I reflect on a high level of selling involved in getting a decision implemented, I wonder how I could have provided more information or context to the situation in order to move up the scale towards more employee “no brainer” decision acceptance.  I also find myself throughout the day moving up and down the scale for each unique situation that occurs.  By setting the goal of trying to be more closely aligned with the employees with authority in empowerment side of the scale in most situations, one can begin to determine where, on average, your team’s level of empowerment and delegation is at.  If you find yourself frequently telling or selling decisions, take a step back and try to determine what are the barriers to moving up the scale and take steps to change your approach to see if you can indeed move up the scale.  Take note of the techniques you employ that move towards employee empowerment.  You may find a pattern that the trend is positive for your team or a particular individual that you can continue to leverage going forward.

In summary, I find Appelo’s self organizing teams to indeed be a more natural way to capture how IT professionals work.  Keeping with that model, employee empowerment and delegation are a great way to look at how to build a strong team.  The authority in empowerment scale is a good tool to help measure the level of effective employee delegation that is taking place within your team.  By using the scale, one can identify where one finds oneself telling or selling.  This further enables one to try different approaches in future similar situations to see if one can move from telling and selling to advising, confirming and true delegation.

I think it is safe to say that anytime any company wants to get something new accomplished they “kick off” this thing called a “project”.  Now if you have spent any time in IT you have probably had a role on one of these so called projects.  You know when you are on a good project:

• Everyone knows what the end goal is.
• Everyone knows each others roles.
• Everyone has a sense that all participants are accountable for their tasks.
• Things are getting done.
• Everyone feels a sense of progress.
• Everyone feels a sense of team.

You also know when you are on a bad project:

• Everyone is seemingly bumping into each other.
• No one can really articulate the goal of the project
• No one knows what the end state is supposed to look like.
• Time is going by with meetings and minutes and status reports but no real tangible work is getting done.

This series of articles will cover different aspects on how to survive as a IT manager that has a role to play on an IT project.  The first article in the series is here.

First recommendation: delegation of project attendance duties.

First and foremost, you must admit that you can’t be everywhere at all times.  You can’t be in every meeting.  You can’t ask every question and get the answer first hand.  Thus, you have to develop a system for determining if you need to know about a particular project or not.  And if you do, do you need the information first hand or would a staff member be able to gather the information for you.  One easy way to determine if direct attendance is needed is if peer managers are planning to attend.  Although this isn’t always easy to determine, just because the invite list has a laundry list of names of peer managers doesn’t mean they all will indeed be attending directly.  This is where having a sly way to contact the meeting organizer and schmooze yourself a list of who has accepted, denied and not replied is helpful.  If all this recon fails, error on the side of caution and attend.  A brief note, if your company has multiple locations, dialing to a meeting via conference call rather than attending in person can be an efficient way to get the information you are looking for without sacrificing valuable hours of the day.  A word of warning, if all your peer managers are in the room and you are on the phone, you will potentially miss valuable non-verbal and post meeting chatter.  Thus, choose your attendance vehicle carefully.

If the focus of the meeting is not geared towards managers and your peer managers aren’t attending, then seriously consider delegating attendance to a staff member.  If you team is full of heads down engineers who would rather be hands on with technology rather than sitting in a meeting hear about some else talk about what some project is going to do with technology, then try and spread the meeting attendance burden around so no one gets dumped on with meetings.  I’ve found that if you are overtly clear on exactly what you need this staff member to absorb, things usually go well:

Boss: “Bob, I have a conflict and can’t make the FlimFlam Upgrade kickoff meeting.  I need you to attend and gather some info.  Specifically, you should announce yourself as part of our team and explain you are in attendance to understand the scope of the project but are not assigned as a resource.  For any resource assignment, have them give me a call.  What I think the team needs to know from this meeting is if the FlimFlam software is going to need a widget to interface with the accounting service.  Thus, if by the end of the meeting no one has mentioned the need for a widget, please ask directly if the project scope includes the requirement to build a FlimFlam to Accounting widget.  After the meeting, please let me know how the meeting went and if a widget is needed.”

What do I need to know?

Obviously, as you are more in the routine of having staff members attend meetings, the level of formality to the request to your staff can relax.  Just a word of caution, in the process of relaxing, make sure you still put energy into making sure the role the staff member plays and the questions you need answered are made clear.  It is easy to relax in these frequent requests to staff and if you start assuming the staff member knows what you need from them without explicitly confirming with them, you run the risk of have lost a premium opportunity to get info when you need it.

Next recommendation for the next part in the series: strategically determine when you and your team need to not be connected to a particular project.

I think it is safe to say that anytime any company wants to get something new accomplished they “kick off” this thing called a “project”.  Now if you have spent any time in IT you have probably had a role on one of these so called projects.  You know when you are on a good project:

• Everyone knows what the end goal is.
• Everyone knows each others roles.
• Everyone has a sense that all participants are accountable for their tasks.
• Things are getting done.
• Everyone feels a sense of progress.
• Everyone feels a sense of team.

You also know when you are on a bad project:

• Everyone is seemingly bumping into each other.
• No one can really articulate the goal of the project
• No one knows what the end state is supposed to look like.
• Time is going by with meetings and minutes and status reports but no real tangible work is getting done.

This series of articles will cover different aspects on how to survive as an IT manager that has a role to play on an IT project.

Attend the project kickoff or not?

Boss: <thinking out loud> “Did they actually get approval to kick off the FlimFlam Upgrade project?  I better have someone on the team plugged in so I can tell if we are going to have to change our procedures in anyway.”

Boss: “Bob, looks like the FlimFlam Upgrade project needs a resource from our team and based on our team’s workload, I am going to give them your name.”

Bob the Engineer:  <forcing a look of enthusiasm> “Thanks boss, I’ll get right on it.”

As an IT manager, I’ve found my role related to projects to vary based on a variety of circumstances.  Some projects, I want to be heavily involved because the project’s scope suggests some potential major changes to my team.  On other projects, I want myself and my team to specifically be completely devoid of any knowledge the project was going on in order to avoid having resources consumed on a project that had a high likelihood of being cancelled down the road.  One thing to note right at the start, a manager, not explicitly sponsoring the project, getting involved on a project impacts the project differently than if a staff member gets involved.   When managers are tactically involved, it usually means something is going wrong and someone probably messed up.  Thus, one of the first decisions to be made is do you, yourself get directly involved or do you assign a role to one of your staff to fulfill on the project to get you the details you need.  The larger the organization and the more enterprise-ish your role then the more information you need to have on all of the projects in flight that could impact you and your team.

That being said, I’ve seen too many new managers, especially ones that are moving from engineering into management, that make the mistake of assuming they personally must know everything about everything that is going on around them.  You have probably run into these types.  They always appear in a constant state of stressfulness.  They are rushing into every meeting a few minutes late and rushing out as soon as the final agenda item is discussed.  They always speak twice as fast as everyone else and they never stick around after the meeting where the real information is shared.  In their quest to know everything that is going on they put themselves on a fast track to mistakes and burnout.  Thus, we arrive at my first recommendation for the next article in the series: delegation of project attendance duties.