Episode 5: Strategy

The team that I took over had a vacancy on it.  During one of my early conversations with Robert he said that filling that position should be one of my top priorities.  Robert told me a story about why the position was posted the way it was.  We were (at the time) looking to a SharePoint specialist to supplement the SharePoint responsibilities of the team.  The story was that in early 2015 we lost our most experienced SharePoint specialist and their were two individuals with relatively little experience to support our SharePoint environment.  Due to the lost of experience and our pending upgrades to SharePoint 2013 and eventually SharePoint 2016, Robert was seeking a third person to focus on supporting our SharePoint infrastructure.  I questioned Robert’s conclusions because, even thought SharePoint is very important to my organization, our SharePoint environment is really not that big.  Early in my time with the team I found this blog post from Mark Rackley about the size and make up of a SharePoint team.  Bottom line is that to support a user base of 5 to 10 thousand people you need nine to twelve people.  My organization is a full order of magnitude smaller than that, 600 users.  Two people should be enough to support our SharePoint environment with some supplementing talent from consultants to help with major projects or upgrades.  At the same time, I held a meeting with the team to review and outline all of the different responsibilities that we as a team had.  I used this exercise to help everyone see the bigger picture about what was going on across the entire team but also to solicit input into what should be done with this open position.  The team identified web/html technologies as the area that we needed the most help in and recommend that we hire a fourth programmer to focus on web technologies.  They sighted several large 2016 projects and the possibility to assist with branding in the coming SharePoint upgrade.  By the time I started my third month in the new role I was able to focus on the stories and assumptions that my predecessor and my team were making about this open position.  For better or worse, I choose not to trust neither of the assumptions and stories and validate the needs against the data from our work tracking system.

Let me start by explaining what we track in our work tracking system, TFS.  We track work items that map to emergent support requests (work we allocate time to but don’t plan for) project work (that we do plan for, see my earlier post Plotting a course) and we track recurring “meta” work (that include things like training, weekly tactical meetings, one-on-ones, etc.)  We also track time for the different tasks.  I could look at the work we completed during my first 10 weeks on the job and compare that to the project plan from our tri-annual meeting to identify the type of work being done and the talent needs for the team for the coming year.

The Platform Services Team supports numerous systems and they each require a slightly different skill set to support and maintain. To reflect this in my analysis I organized all of the different things we build and support into a two tier hierarchy with the TFS Area field.  For the first level in this hierarchy, I assigned a percentage for how much of the work required an “Analyst” and how much required a “Developer.”  I also when one step further by breaking our SharePoint Analyst and Web Developer based on the stories I heard from my predecessor and my team.  When I looked at all of the Support and Project work (the work that requires specialized talent) that we completed over the last 10 weeks a trend emerged.  Additionally, when I looked at all of the 2016 projects and their initial size estimates that trend contained.  Historically we had 4 FTE’s performing Analyst type work with 2 FTE’s dedicated to our SharePoint environment.  For the developers, historically we had 2 FTE’s performing developer work with one FTE focused on web development.  The projects that we have planned with our business partners for 2016 had similar expectations for the type of talent that would be required from the team.  With one team member focusing solely on web development we appeared to have our development needs covered with the existing staff.  With two team members focusing solely on SharePoint, we also appeared to have our needs covered for SharePoint with existing staff.  With the numbers showing me that we are, and expecting to continue, to spend more time than available talent performing Analyst type work, I decided that we needed to hire a fourth analyst.

Graph of FTE work on the team

When I shared the results of the analysis with the team they were not immediately aligned with this, but after focusing on the data and the story it told most everyone accepted it and a logical direction to take the team.  Below is an excerpt from my team strategy document that focuses on the team structure that this analysis helped shape.


We informally view ourselves as multiple teams under a single organization structure.  The needs of the organization are dynamic but by organizing ourselves in a ridged manner we reduce our ability to meet the needs of our Business Partners.  As a result of this rigidness, we struggle (often as individuals) to meet peak needs from our Business Partners.

The PST is tasked with providing tier 2 technical support and IS project implementation for 4 of the 7 divisions at Associated.  At the beginning of 2015 there were 8 team members dedicated to these business units.  Through attrition and reorganization, at the end of 2015 there were 6 team members dedicated to same business units.  This downsizing has created islands and single point of contacts for several business units and products that the PST supports.

AECI has strategically operated as a fiscally lean organization.  Information Services supported this strategy by eliminated operating and capital costs from the organization by creating in-house software products.  Starting in the late 2000’s, this strategy started shifting as the costs of purchasing software products became lower than the labor costs of building software products.  Today our product strategy is to rely on the market to provide software solutions and Information Services can customize and extent, and to build software where the market does not exist.  Job roles and descriptions have not kept pace with this change in strategy.

Guiding Policy:

Data from 2015 and the project outlook for 2016 indicates that a large amount of effort has been (and will continue to be) expended by Analyst talent, or developers performing in the analyst role.  As a result, better definition of the Analyst role and the Analyst career path is necessary.  Additionally, the PST requires a high degree of specialization with the SharePoint Product. Critical mass for supporting and maintaining our SharePoint environment is 2 FTE Analysts.  As such, we should explore new job descriptions that reflect this specialization and evaluate market data of SharePoint analysts vs. generalist analysts.  Finally, the existing open complement position will be filled as an Application Analyst with emphasis on the AssurX platform.

Historically, the members of the PST have been dedicated to a Division within AECI.  This practice has served AECI well in the past; however, in our current environment, this has left individuals islanded and silo’d.  Members of the PST do not have backup for their critical tasks.  As such, the PST will treat itself as a Talent Pool;  team members will align themselves with job role and not with business unit.  The PST will be viewed as a tier two IS support organization and IS project implementation team for 4 of the 7 divisions at Associated.

Knowledge silos must be eliminated.  The PST has historically been a software development organization; that coupled with historical formal and informal divisions of the team, has created an environment where many critical line of business systems are supported and maintained by a single team member.  As our Analyst role is better defined and the new analysts ramp up, this pattern must change so that Analyst are the primary support for critical products and developers serve as secondary support.

Development staff will focus on minimalist, web based, technology stack for custom application development.  This will enable the developer team members to create and support a multitude of applications that serve business partners outside of their traditional area of focus.

Episode 4: Plotting a course

At the beginning of my second month, I had clarity on my immediate expectations from my manager.  Additionally, all of the team’s emergent work was being managed through a Service Level Agreement with assigned deadlines for all incoming requests.  With clarity provided, my focus turned to our tri-annual project planning process.
To begin my preparations for the tri-annual project planning, I started by organizing all the team projects into a central location in OneNote.  Active projects where pulled from other places in OneNote, TFS, and people’s heads.  When everything was collected there were a total of 51 active projects.  Fifty-one active efforts for seven team members, that’s more than seven per employee!  How on earth could anyone function with seven active projects?  As I dug deeper, I began to discover that there was some serious house cleaning that needed to happen.  Many of the projects were in fact completed, some years ago.  Some projects were so small that they really were not worth the effort it would take to plan them out, so we started working on them through the Service Level Agreement.  Finally some of these projects were still only ideas and in a planning phase.  After cleaning up everything, I was left with about 30 projects to plan out for a team of 6 for 2016.   With all the active and anticipated projects defined in a central location, my next effort was to standardize the way that  our project work was tracked and documented.  This was not a difficult as you may thing because many people were already using OneNote and the tool for documenting their project work.  Each project had a documentation hub created (a section in OneNote,) and each project was given a project work item in TFS (for work tracking.)  With this base established I could now have an intelligent conversation with my business partners about what projects we should be undertaking for them in 2016.
The Tri-Annual update has its roots with our former CIO.  This originally started as a quarterly update the Information Services gave to each of the other 6 divisions at Associated Electric to update them on the various projects that IS was undertaking on their behalf.  This started as a communication tool that our CEO implemented to improve communication and collaboration between IS and the other divisions.  Today, under the leadership of our current CIO, it is an open forum to present Information Services’ KPI and gain alignment on our project plan.  To create an initial project plan for the different divisions we estimate the size of each project using “Project Points.”  There’s a complicated formula that determined the definition of a Project Point but the simple explanation is that one point is about 100 man hours of effort.  Each business division is assigned a budget of project points based on their needs and the amount of time that the team was able to on projects in the last 4 months.  With size estimates and budgets, we simply let our business partners elect how to spend their points, see below.  The output of this exercise is the proposed project plan for the next 12 months.
At the end of the planning session a project plan document is produced and that is then distributed to the managers of the business unit for their review.  Immediately before the start of the new trimester (December 1st) the CIO and the IS management team meet with the director and managers of the business unit in the “Tri-Annual Update Meeting.”  Two of the business units that I support are fairly small and they do not have many projects to discuss so the updates to those two groups focused on the IT group and my team and how well we were resolving their support requests.  The Accounting and Finance division is the largest business unit that I support and, as such, they have the most needs from my development staff.  In addition, I had just lost a member of the development staff that historically supported accounting to Michael’s team as back fill for me leaving.  This meeting was fairly tense.  I was leading the conversation on the project plan and there was two points of contention, first a single project on the plan was taking over half of their available project points for 2016 and second, they didn’t feel they were given enough project capacity.  I directed the latter part of the conversation around the fact that capacity was governed by team members and now the aggregate team was down two team members (one for the back fill and one vacancy that was dedicated to SharePoint.)  The conversation lasted over an hour and a half and led to some very good discussions about how accounting should best spend their project points.  At the end, my liaison and I left needing to do a little of revision to our project plan but all the managers were agreeable to that plan.
I have two lessons to share from this part of my experience, first the importance of preparation.  I spend many days reviewing, pruning and cleaning up the documentation related to all of the team’s projects.  This was time well spent and it made the planning sessions and the actual updates fairly easy and empowered me to speak knowledgeably on all areas of my new team.  Second, in difficult conversations, stay focused on the facts.  The accounting team was, understandably, unhappy with the loss of capacity from my team, but keeping them focused on the facts and the why helped smooth that conversation over and kept us focused on the important parts of the conversation.

Episode 3: Getting Bearings

Picture of Kanban board

After the first week in my new role was completed I was ready to get down to business.  Based on my one-on-one conversations with my new employees, I had some direction on where to direction on where to start, but the todo list was daunting.  Hiring two employees (one part time and one full time,) learning about my new business partners, standardizing work practices, standardizing project planning, better defining job roles and descriptions, just to name a few.  Unfortunately, all of these items would have to wait until my third week on the job.  My second week on the new job was filled with a previously scheduled user conference that I had committed to speaking at.  This was very unfortunate timing. This timing was made worse by the fact that it was an intentional decision.  As I learned, it is critical to spend as much time as possible with you new team and you manager during the first few months in a new role.

As soon as possible, you should meet with you new boss and clearly establish expectations during your ramp up period over the first 90 days.  My first week on the job, my boss, Robert was at a conference in Philadelphia and the second week on the job I was at a conference in Chicago.  As a result, my first real conversation with Robert in my new role didn’t happen until the third week on the job.  This was undesirable, not because I was moving in the wrong direction with my new team, but because I didn’t have clarity on what Robert’s top priorities were for me in my new role until my third week on the job.  During this conversation, Robert identified his top priority as having the upcoming Tri-Annual updates go well.

The Tri-Annual update has its roots with our former CIO.  This originally started as a quarterly update the Information Services gave to each of the other 6 divisions at Associated Electric to update them on the various projects that IS was undertaking on their behalf.  This started as a communication tool that our CEO implemented to improve communication and collaboration between IS and the other divisions.  Today, under the leadership of our current CIO, it is an open forum to present Information Services’ KPI and gain alignment on our project plan.  The team that I had inherited had a very wide variety of was to track and manage their work, so getting KPI’s and putting together three formal project plans in four to six weeks was a fairly tall order.

In Information Services, we break our work apart into three categories: project, support and meta.  At this time, most of our KPI’s revolved around the “support” type work.  This is type of work (for my team) is typically your tier two help desk type work.  We don’t plan for this type of work; but rather, we budget a percentage of time for this type of work and strive to complete this work as quickly as possible.  Standardizing emergent (support) work became my primary focus for the team.  Without a standard was to track our support work, I would not be able to compile any support related KPI’s.  Many of our teams use Team Foundation Server for managing our work and that was the system of record that my team was going to start exclusively using.  Accomplishing this required everyone to get out of the habit of immediately resolving support requests and into a habit of documenting what they were being asked todo.  To make this easier, we kept it analog and a created a physical Kanban board on some of the exterior cube walls.  I clearly laid out the expectations for the team that, at a minimum, every support request that you receive needed to be documented on a 3×5 index card.  No entry into TFS if they didn’t want to, I would take care of that and allow them to focus on the work.  Some of my employees habitually recorded everything into TFS, but for those that didn’t, my gesture greatly improved their buy in.  After all, I was only asking for a few words to be written on an index card and pined to the cube wall.  The results were immediate, we went from about 5 recorded tasks a week, before I joined the team, to an average of twenty.  The second problem to solve was to ensure that team members that habitually used TFS properly categorized their work for future analysis.  This was easily accomplished by using a TFS query pinned to the home screen in TFS.  Below is a picture of the Kanban board and the TFS home screen that I use to keep all the work straight.

Picture of Kanban board
TFS home page
At the end of my first month, the entire team was now managing emergent work in a consistent manner and we were beginning to collect KPIs to measure and improve our performance.  Lessons I learned include avoid traveling during the early days of the transition.  During the first two weeks in my new roll, I did not have a chance to speak with my new manager because either he or I were out of town.  This cause delays in the two of us gaining alignment on immediate priorities, preparation for the triannual updates.  That said, the best thing you can do for yourself when entering into a new role is to have a direct conversation with your new manager to negotiate and align expectations.  Once we had that conversation my focused immediately turned to the triannual updates.  That preperation would continue into the second month with a focus on the team’s projects.

Episode 2: Landfall

Good leaders are multipliers of talent.  They can take the three individuals and have them produce the output of six individuals.  On day one in a new leadership role, all leaders are a talent and value drain; they actually take away value from their organization.  Think about what you do on your first day in a new job, go through human resources, read policies, etc.  It could be days or even weeks until you are able to start doing the work you where hired to do, never mind the fact that you may not be doing it well in that early phase.  The message from the first post was to build a plan for your transition.  Building a plan will help you get to the point where you can add value sooner.  Michael Watkins refers to this as the “break even point.”  In the first week in a new role, you will not step in and start adding value; however, there are a few things that you can be doing early (and some missteps and you can avoid) to help you accelerate the break even point.
My approach to the first week was inspired by The Five Dysfunctions of a Team.  In this story, Jane (the fictional CEO) started her first two weeks on the new job as a listener.  She attended the regular meetings, spoke individually with her new employees and focused on learning all she could about her new team.  I modeled my first week on the job after that.  The transition plan I created called for a series of conversations with my new team covering everything from personality to their current projects.  I also built in time to speak with critical business partners.  The only person that I did not spend a significant amount of time talking to and learning about was my new Manager, Robert.  These conversations and the learning that occurred was all directed and inspired from the The First 90 Days.
The First 90 Days includes a concept called the learning plan.  The learning plan is a involves identifying questions that you want to learn the answers to, building hypothesis and then testing them and refining the questions you are asking to progressively increase your knowledge about your new team.  Before staring my new role, I created a list of 5 questions and my hypothesis for each of them.  During my conversations with my new team, I tested the hypothesis and built an action plan for the next steps for learning.  The single more important thing I learned was that there was a lot of confusion about individuals job roles on the team.  Why was this?  How did we get to that?  What did everyone view as their role on the team?  Those became my next focus of learning.  Answers to these questions would be very influential in the future as a starting building a strategy how to run the team near the end of the 90 day journey.  At the end of this post are the 5 questions that I was seeking answers to from my Learning Plan.  Learning was necessary and a positive way to start the new role; unfortunately, not everything was pleasant on that first week.
On the last day of my old role, I was very concerned.  I had not told any of the people I had work closest with about this transition, that I would be leaving and Michael would be taking over the work I was doing with them.  After expressing my concern with our CIO, he agreed that I should go ahead and communicate this to a Sr. Manager that I worked closely with.  The conversation went like this
Me: “I’m sure James has already given you some details about this this transition …”
Manager: “Not really, I heard something from my boss about this, but this is the first conversation I’ve had about this …”
It turned out that my former manager had told a Division Director (manager’s boss) that Michael was inline to replace me and that it would likely happen before the end of the year.  I personally called one of the women I had been working very closely with over the last 18 months that evening to let her know.  There was a lot of confusion, excitement for my opportunity, and hurt that this had been kept in the dark until after the 11th hour.  In total, 3 people, outside of my department (old and new) and HR, knew about this transition before it happened.  Monday, as the word got out with my business partners, was a day filled with negative emotional reactions.  This created a mess for myself, Michael , James and Robert to clean up, and it took a lot of energy to do that.  To make the situation worse, both my prior and current managers were out of town that week.  Email and phone calls between sessions at the conference they were attending was the only opportunities for them to assist.  The final announcement came out on Thursday when Michael and I traveled to the monthly leadership meeting at our power plant in Oklahoma.  This cost me a day with my team but it was necessary as all of the managers and leadership that I had been working with for the last 8 years was present in one place.  You cannot under estimate the power of good communication, or the effort it will take to repair poor communication.
Coming into my new role with a plan made that first week relatively easy.  Any leader tranistioning into a new role should prepare, plan and make assumptions about your new role, but be prepared to be wrong on them.  That’s okay, what is important is that your learn and grow from you incorrect assumptions.  The things that made my first week difficult issues around timing and communication.  The feelings from the people that I worked with was that this change was a big secret.  It was not.  I have learned that it is important to be as transparent and preemptive in your communication of the transition as possible.  On the issues of timing, you should avoid starting a new role when your new boss is out of town and you should also avoid being out of town as well.  Having your new boss there to bounce ideas off of a soliciate feedback is important, so is spending as much time as possible with your new team in that critical first week.
The questions from my Learning Plan:
  • How has this team performed in the past? How do people in the team think it has performed?
  • What efforts have been made to change the team? What happened?
  • Name three things that if we accomplish in the next 12 months would constitute for the team, i.e. what would make 2016 a good year?  Why?
  • In what areas is the team most likely to face challenges in the coming year? What are these challenges (technical, cultural, political?) What can be done now to prepare for them?
  • If you were me, what would you focus attention on?

Episode 1: New Horizons

The story of this transition actually began six to nine months prior to me taking the helm of a new team.  Early in 2015, Robert came to James to ask for help.  He was in a rough spot for a newly appointed manager.  He had newly appointed supervisors and supervisors that were increasingly dissatisfied with their roles.  Additionally, Robert had a team of software professionals, the “Platforms Services Team” (essentially the SharePoint team at the time) reporting directly to him.  All of this, while reporting to a new CIO, made Robert’s role a very difficult one.  It was in early 2015 at one of our department strategic meetings that this subject came up.  There was some lively discussion around department organization and supervisor movement but very quickly a common theme emerged, I would be leaving my current role and joining Robert’s team.  We left that discussion knowing something was going to happen but without knowing when.  At this point we were still several months away from anything happening but it was already time to start preparing for this transition.


My earliest preparation focused on two areas, growing a team member to succeed me and building and strong relationships with my potential new boss and colleagues.  James has already helped solved the first problem by create what he has called the “L-Team.”  This is all of the supervisors in the department and individuals that have identified management as a possible career path.  Fortunately, I had a member of my team, Michael, that was part of this group and was already working towards becoming a supervisor.  At this point, all of my technical employees had goals to grow and focus on specific technologies to establish deep skill sets across the team.  Immediately I change Michael’s focus from depth to breadth of technology.  This was to enable him to have enough technical skills across the teams technology sets so that he could be an effective coach to the team one day.


To address the second concern I immediately asked Robert to start mentoring me.  This was mostly driven by the fact that Robert was potentially my next manager, but also driven by the fact that the was further along in a career path that I was, and still am, looking to follow.  Over the month that followed I meet with Robert on several occasions.  Looking back, this was a great way to jump start our relationship but too short to be a good mentoring relationship.  I also focused on building relationships with my potential colleagues in Robert’s Department.  This was accomplished with a series of lunch conversations that would always start as a conversations about projects or common concerns to make the conversations safe but they would quickly grow beyond those seed topics.  I was able to carry out about a half dozen of these conversations over a six month period.  I would recommend more but once a month seem to be the best I was able to do at the time.


Finally, at our August strategic meeting that included the leadership group (managers, supervisors and aspiring supervisors) from James’s and Robert’s departments, the team came together and made the recommendation that I move to supervise the platforms team and that a member of my team be moved into a development role to supervise my current team.  The output of this meeting was a recommendation that was taken to the CIO.  There was no plan or timeline for implementing this change and so it sat on the back burner for the next month.


During this month in limbo, Michael and I were almost at a loss on what to do next.  On one hand, this “recommendation” had already been communicated to our department; on the other, we were not allowed to talk with out business partners about it.  In my opinion, this was the first of a few communication mis-steps on the part of my manager.  The ramifications of these missteps will be discussed in the second post.  While we were in the limbo state, Michael and I agreed that going forward he would be (for all intents and purposes) running the team.  Michael started running and leading all of our planning meetings, project meetings and became accountable for our team’s KPIs.  Over this month, Michael started attending and participating in (but not let leading) all of our external facing meetings.  A detailed plan had not yet been created but Michael had already stepped up into the role.


At our September strategic meeting, there was a new sense of urgency towards building and executing on a transition plan.  It was discovered that Human Resources was placing a freeze on all employee position changes at the end of October, in five weeks.  We quickly hashed out a plan covering the major events for the rest of the year, tri-annual project planning, employee evaluations, and leadership meetings.  This plan covered who had responsibility for which events, for which team and when.  This plan also included me transition to the new team as soon as possible, October 12th, in less than two weeks.  At this point, I was nearly lost.  In less then two weeks I would be leading a new team.  That team was more than twice the size of my current team and directly (or indirectly) supported 4 of the divisions at AECI.  What really concerned me was that I didn’t yet have a plan for what to do once I got to the team.


This change was coming very soon and I was lost as to what todo.  I knew that I was not the first person to do this type of job transition before; therefore, I did a quick google search and I discovered The First Ninety Days by Micheal Watkins.  I immediately committed to reading this book and applying some lessons into this new role.  In the week before the transition, i met a few times with my new manager and conducted a few conversations or excercises from the book.  We jointly completed a STARS portfolio of the team, had a conversation around expectations for the rest of the year, and reviewed my personal 90 day plan.  This book was very influential in guiding me through this transition and I would recommend it to anyone in a similar situation.


This post covers all the events leading up to this management transition I recently underwent.   This is really more of the setup and back story about this transition and less on guidance, advice or lessons learned at this point.  Even this early into the story there is one lesson to share with anyone who may be going through a transition like this and that is to have a plan.  With a plan inplace, you will hit the ground running; you will likely be running in the wrong direction, but a plan on day one will give you momentum and credibility.  These are a critical in having a successful leadership transition.  Good leaders will always be able to read their situation and adjust course as necessary.  Below are some artifacts, including my 90 day plan.  In my next post I will go over the events of the first two weeks in this new role.