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.