Midwest IT Survival

Today's IT Projects Need Transparency to Change

For large organizations it seems that as technology grows more and more integrated, IT related projects become more complex and thus longer in overall duration. There is no doubt the rise in cloud/SaaS solutions has exacerbated this increase in overall IT project complexity. I’ve written on the impact of cloud in this manner prior here. Gone are the days of a large corporate IT shop having a project manager engage the same three or four familiar delivery stakeholders and with little outside involvement, execute the project beginning to end. This increase in technical integration means a project manager can no longer count on those three or four stakeholders having the cross systems knowledge and technical systems access to implement changes as crisply with few artifacts as to what the project has done/is doing/when/etc.

To help illustrate this evolving shift, consider the following hypothetical large corporate IT conversation:

PM: “Welcome everyone to the FlimFlam upgrade project’s twentieth weekly status meeting and a special welcome to Jim who is joining to help sort out all the changes that impact others outside of our core team.”

<General welcoming gestures and verbal niceties ensue>

Jim: “Ok, is there any diagram that captures all the flows of data in and out of the current FlimFlam system?”

Core Team: “Um, no, we just know them from working on FlimFlam for the last five years.”

Jim: “Um, ok, have you mapped out what new features of the upgrade are turned on compared to off and who would be affected? Or say, documented the link between the features and business requirements?”

Core Team: “Well, not documented, but we know HR wants the real-time instead of batch interaction and Operations wants better reports. But HR outsourced last year to a cloud provider and we have no idea what Operations is doing …”

Jim: <thinking to himself> “… oh boy, good people, but this project is looking like a train wreck already …”

Clearly a “business as usual” approach to this upgrade isn’t going to work any more.

In the past, with so few stakeholders having comprehensive access to the silo-ed systems impacted by these types of changes, the need for easy to digest transparency into what changes were going to happen when and how was not critical. Sometimes the only visibility to what such a small project team was doing was in the production change management review and approval process:

Change Control Board: “Ok, next up is change record number 72,578 which reads ‘Enable the employee web portal to support the time off calendar’. Anyone here have any concerns with this change? Hearing none, approved. Next on the list …

Today’s Problem: IT systems are too interconnected for lack of project transparency to change

Sounds like 72,578 is a simple change that an HR delivery team of the past could have easily implemented without much cross team impact. But today, that example time off calendar may need to interact with the HR system to record those time off days against how many the employee actually has as part of their compensation package. There probably is a need to support some management approval work-flow. Plus, there are probably other work scheduling systems and PMO resource planning tools that need a feed of that data in order to accurately support their user base. There is probably some single sign on/web access management technology involved to support all employees accessing the web portal, some central provisioning system to handle access plus some remote access needs to support today’s mobile workforce. It is probably safe to assume that some of those integrated systems are in-house and some are cloud/SaaS or a mix of all of the above.

Additionally, with matrix-ed internal and external project resources with contracted and off-shore delivery coupled with the “cloud” vendor resource engagement model, a simple change could have a variety of stakeholders in need of agreement on what is changing when, etc.

Thus, hopefully I’ve convinced you that something as simple as a web portal for employee time off entry can involve a number of different internal and external teams and systems that all need to coordinate changes to support the business objectives of this example project.

So how does this all drive the need for “transparency”? Isn’t this just a basic PMO 101 issue of dependency management and cross project impacts?

Yes and No

The project team needs to produce deliverables that don’t just get the core team in agreement to pass the next quality gate in the project life-cycle (never to be revised again); the project team needs to produce deliverables that outline, at a high-level, the following basic project elements:

• Scope of the project in a sentence or two
• What is changing from present to future state
• Who is impacted by the change (and have they been engaged)
• Lastly, what isn’t in scope (that a non-core stakeholder might assume is in scope)

… for non-core stakeholders to easily digest and understand … and update the material frequently to have at the ready anytime it might be needed.

Besides an effective communications vehicle, another subtle yet important aspect to this deliverable is its ability to build confidence in the effective management of your project in outside stakeholders. This confidence can lead to senior management getting the impression the project is “under control” and move on to another project for increased scrutiny rather than assigning all kinds of ancillary people to dig into your project to figure out why they don’t have that “under control” feeling.

Stated another way, large corporate IT projects today need to adopt a bit of “program management”, specifically, some of the enterprise reporting themes. A Gantt chart (which I’ve extolled the benefits of before here) isn’t the end-all-be-all here. A slide deck that contains a few slides covering these topics with lots of pictures and drawings where ever possible would be more effective in serving this communication need.

So if you are a project sponsor or a project manager, consider having a communication deliverable that is actively maintained, even if your PMO PLC doesn’t explicitly call for one, to provide simple and easy to digest transparency into key aspects of your project at the ready at all

Produce a Business Case Deliverable

In the first part of this series on senior management communication for those more comfortable with grep-ing an exception log or tracing through lines of code to find that elusive bug the conclusion was:

No matter how technically proficient you are in your respective discipline, not investing in effective communication skills will limit your over-all effectiveness in your organization.

In the second part of this series, we used an example of engineer Bob recommending his company invest some cash and resources into an operating system upgrade. The initial logical conclusion that a sequence of facts surrounding how awesomely technically cool the new OS is would convince anyone to make the investment. Yet, spewing facts isn’t as compelling as it is to:

Relate the facts and figures to senior management’s goals/vision

To do this, structure a presentation into a story following this sequence:

1. Describe the Current State including gaps/challenges/issues/problems
2. Describe the “Optimum” Future State
3. Describe the Roadmap to get from Current to Future State
4. Outline the immediate next steps to get started on the Roadmap
5. Throw anything ancillary or supporting to the above 4 steps in Appendices

In the Bob’s case, consider “telling the story” of ultimately what aligns to senior management’s goals/vision in this example context: computing capability at reduced cost.

Using the above sequence as a template for Bob:

1. Current State

• Number of servers running prior OS, server count over time
• CPU utilization
• Maintenance costs (total cost of ownership if it can be computed, support contract costs)
• Indicators when “bad news” like special support contract costs, etc. show “doing nothing” is a negative
• Intersection with any other projects that need capabilities provided by your Future State

2. Future State

• All servers running new OS phased in over timeliness
• CPU utilization
• Maintenance costs

3. Roadmap

• Upgrades broken into simple chunks
• Chunks representing some useful grouping (rather than random)
• Testing or other functions supporting the upgrade
• Costs over the duration

4. Next Steps

• $$$ approved to buy hardware
• $$$ approved for 2 resources
• Initial steps within your organization to get a formal project going

5. Appendices

• Data showing why 2 resources are needed, what happens if you get 1 or zero or 12
• Any other data, facts, figures around “hot button” issues that might come up like a trend to out-source or in-source work, strategic vendor partnerships, etc.

Your goal in telling this story is to have a compelling deliverable in the form of your presentation that conveys to anyone that it would be just plain silly not to execute your roadmap. That “anyone” needs to be both technical and non-technical people. I am certain your technical peers are going to be 110% behind anything that involves implementing new, cool technology. What techie holds the position of “nah, I still want to be a Windows 98 shop.” At the same time, the more holes that can be poked in your analysis the more likely your great idea is going to get trampled by the masses and not acted upon.

Sure, others might suggest not putting this much effort into a request that “should just stand on it’s own to support action”. A recent (how timely!) tweet from @rands suggests as such:

And although it might seem highly desirable to be able to convey your technical request in words and have immediate understanding and support, those veterans of large corporate IT shops know there is a big complex organization with overlapping, competing and sometimes contradicting priorities that can easily mount a campaign against your plan. Thus, those quick to dismiss the value of a slide deck deliverable in corporate IT might be missing a critical element of this series: producing a deliverable.

Sure, once you have a deliverable out there others can still mount a defensive. But, you also empower your management with a strong case to move in your direction that can be forwarded along and forwarded up. The more compelling your story, the more it stands on its own as a viable business case to make a strategic company investment the more the financial/business minded in IT will be able to comprehend and support your plan.

So, before you write-off the value of putting the effort into crafting a story deliverable that compels the non-technical decision makers to act on your plan, consider the alternative: a verbal request to spend money on some cool technology? If you are planning to invest a significant portion of your own money, do you want to buy some cool technology or act on a strategic technology investment with data backed returns?

Raw technical data won't speak for itself

In the first part of this series on senior management communication for those more comfortable with grep-ing an exception log or tracing through lines of code to find that elusive bug the conclusion was:

No matter how technically proficient you are in your respective discipline, not investing in effective communication skills will limit your over-all effectiveness in your organization.

Thus, if you were following the argument to support this claim, you appreciate the notion that, ultimately, there are diminishing returns to exclusively honing your technical skills to perfection without making investments in your executive communication skills. Your frustration level will continue to rise as you see decision after decision being made against your common technical sense.

You need to assist senior management with data to aid in shifting decision making to include your technical vision.

In being pragmatic, this “shifting” is more analogous to turning the Titanic than a row boat. No fancy PowerPoint deck with brilliant technical strategy in-line with corporate objectives backed by irrefutable financials will guarantee decisions in your favor. There is an element of decision making that involves emotion that just can’t be trumped by reason 100% of the time [evidence].

As an example, a certain executive may favor one vendor over another. No matter how many Forrester Wave or Gartner Magic Quadrants you quote touting a vendor’s industry recognized superior product, a weaker product from a different vendor can get selected.

I am not saying to give up on collecting data to support your recommendation. But knowing non-logical factors influence decision making, you can appease your engineering brain to some degree, when rejected, with the notion that you exhausted your resources and produced a compelling business case that stands on its own. Plus, you never know if the next re-org will change the senior management decision ownership. You may very well get a chance to make your pitch again with a new audience that might just have a different emotional dynamic that is more in your favor. And since re-orgs occur more frequently the large the organization, you might not have to wait very long. I’ve written about corporate IT leadership change prior.

So, back to the topic of communication and the first fallacy of executive presentations for the technically proficient:

Raw technical data will speak for itself

Fallacy: If you just put your accumulated knowledge down on paper (or PowerPoint) in a logical, fact based sequence, the recommendation will just speak for itself.

Rarely, if ever, have I observed a senior manager approve a decision based on the spewing of sequential technical facts without any questioning.

Bob: “We need to upgrade to RHEL 6 because it more efficiently uses multiple core processors reducing overall OS resource consumption by 10% freeing those resources up for applications to uses. Fact, fact, fact, fact … thus give me two people and $200k to start the upgrade process.”

Those maybe compelling, industry proven, lab test supported facts that indicate some new technical something is vastly superior to what you currently have and the company will benefit greatly, maybe even eliminate some current outstanding problems, reduce costs, and cure cancer … but what problem do they solve or opportunity do they create for the senior manager?

Quickly clarification, “what problem do they solve or opportunity do they create for the senior manager” is not be taken as you need to pander to the whims of the senior manager. This statement should be interpreted as: How do all these facts and figures relate to the senior manager’s goals and vision?

Relate the facts and figures to senior management’s goals/vision

One of the best ways I’ve learned to do this is to structure a presentation into a story following this sequence:

1. Describe the Current State including gaps/challenges/issues/problems
2. Describe the Future State
3. Describe the Roadmap to get from Current to Future State
4. Outline the immediate next steps to get started on the Roadmap
5. Throw any ancillary or supporting data for the above 4 steps in Appendices

In the case of Bob’s desire to convince senior management to invest in an operating system upgrade, consider “telling the story” of ultimately what aligns to senior management’s goals/vision in this example context: computing capability at reduced cost.

Keeping with this logical theme of presenting a story aligning your recommendation to senior management’s goals/vision, the next article in this series will built upon this theme.

Convincing senior management of technical direction requires new communications skills

As a server administrator, you invested in knowledge associated with configuring operating systems to perform optimally and be able to interrogate error logs to diagnose and report problems efficiently. As a software developer, you sought feedback from code reviews and combed forums and blog posts and (depending on when you were in this role) books to improve your code. In your role, you invested in the technical skills that expanded your ability to deliver solutions within your respective discipline.

Being measured on skill-set attainment wasn’t particularly evasive. Your servers were deployed live and they either performed their needed functions in support of applications and end users or they crashed after deployment with a flurry of functional issues reported to the helpdesk. Your code either met the functional requirements and was bug free after being tested or defect reports mounted. There was more direct feedback as to what skill-sets you have mastered and what areas of your respective discipline needed more investment.

Even communicating to your direct manager in these technical roles provided more instant feedback as to your ability to successfully articulate problems, issues and recommendations for improvements due to the frequent interactions between yourself and your manager. And from your manager’s perspective, they were tasked with delivering a service and needed you to execute tasks to meet commitments.

But what about communicating to senior management?

In most cases, you are not directly interacting with senior management on a daily or even frequent enough basis to build implicit trust. You can rarely walk blindly into a budget meeting with senior management and say:

“We need to upgrade all the servers to RHEL 6. In order to do that we will need to buy ten new servers at X dollars each for a total of Y dollars now and we will need two more people to build and swap in all those servers. Of course, we’ll need all the applications to test after each server is re-built. And …”

with senior management responding with:

“Sure Bob, let me get out the checkbook …”

It is almost painful to observe a solid, technical individual attempt to explain a technology need to senior management who hasn’t determined how to effectively communicate that need in a format that senior management can more readily absorb. Equally troubling is seeing a poorly communicated yet real technical need be decided against by senior management based on a weak presentation. You can almost predict the conversation that will happen some number of months later:

“Bob, how come we have to pay this huge support contract on our servers? How come I didn’t know about this earlier?”

“But Sir, I tried to tell you we needed to upgrade our servers before …” This conversation becomes more awkward with each subsequent exchange.

No matter how technically proficient you are in your respective discipline, not investing in effective communication skills will limit your over-all effectiveness in your organization.

So, what steps can one take to make this investment in their communication skills? For one who has focused on learning technology, the shift of focus to learning effective communication skills may seem elusive at first. Thus, consider spinning up a thread in your brain that breaks this down into a logical exercise.

Look for part 2 of this article to dive into some logical steps.

The challenge to integrate Architecture and Agile

Recently on Simon Brown’s blog “Coding the Architecture”, Simon posed are interesting challenge of which this article provides my response. I enjoy Simon’s blog for he presents very well thought out articles on the challenging overlap between Agile software development and the value of architectural principles in providing software solutions. As those that frequent my blog have seen, I’ve written about the challenges of integrating pure Agile development methodologies into non-Agile organizations such as legal services, manufacturing as well as financial services. I’ve approached the topic of work estimation here which is a frequent challenge in non-agile organizations that make project and resource prioritization decisions based loosely on the estimated work effort. I’ve tried to successfully blend Agile story and blacklog project management with the preponderance for waterfall-esk program management here. Based on the comments to that article I didn’t succeed in my goal. I’ve even broached the Agile versus architecture question before here but the focus was on the Agile reducing over architect-ed solutions rather than taking Agile versus architecture head on. I’ve even discussed budget challenges before.

Simon’s challenge: Given a four month window to deliver a new software project in an Agile shop, how would one go about doing so given some interesting constraints? The below graphic is from his blog post that captures the unique constraints for this challenge:

Based on my multiple years in the financial services industry working for more than one bank, I feel the need to outline some immediate assumptions that pop into my mind that are tainted by my direct banking experience:

1. Design Firms – Simon’s challenge involves the bank undergoing a new branding effort. In my experience, a bank’s internal marketing department partners heavily with an outside marketing firm for larger banding initiatives. Additionally, new branding efforts usually involve getting that new brand message out through a variety of channels.
2. Middle-ware/SOA capability – Given the overall growing maturity in the service oriented architecture space and the relative IT budgets of most financial institutions, I am going to assume there is some middle-ware, messaging and/or enterprise service bus-like capability to leverage.
3. Content Management System/CMS – Given the explanation of the current state online banking system, I am going to assume the bank does not currently have a mature content management platform which can be extended to provide online banking functionality.
4. Backoffice – Also, I am assuming that the bank currently has a backoffice transaction system that currently performs the bank’s core bank product transaction needs. For the sake of this exercise, a “legacy” mainframe set of applications are in place that run the core bank transactional services that has some capability to expose those transactions to the middle-ware/SOA platform.
5. Build versus Buy – A classic challenge for banks has been the decision to put the focus on building in-house capabilities versus buying mature vendor solutions and integrating those into the technology portfolio. Depending on the financial health of the bank itself as well as the predilection of the CIO, the build versus buy pendulum can swing to either extreme. Add the frequent turn over of senior IT leadership and this can be a real challenge for enterprise architectural patterns. For the sake of this exercise, the assumption is that the bank is willing to invest in the middle-ware transactional capabilities in-house as well as the supporting online banking application user experience but prefers to purchase a new content management solution to host the UI.
6. Big Bang versus Functional Sequence based rollout – I am also assuming product management is risk adverse and open to sequencing in the new functionality rather than demanding a big bang approach. More on the sequencing later in this post.

Given the architecturally significant changes requested in 4 months, specifically the read-only to real-time transactions and the complete hosting re-platform need, I would convince management that it would be infeasible to deliver everything in 4 months. Yes, the project management side of my brain says don’t over commit given the technical complexity involved and the linkage to a significant customer impacting change.

Thus convinced, I would then break the effort into multiple parallel technical efforts:

Re-brand current site = I would spin up an Agile team including the online banking product management/manager to focus on re-branding the current site between now and the 4 month end date. The team’s priority would be:

1. Integrate the new branding into the current site working heavily with the outside design firm
2. Make changes, assuming no conflict with #1 above, to improve W3C compliance

Create re-useable transaction services = I would spin up another Agile team that has the mission of exposing the backoffice transactional services as “enterprise” consumable web services through the middle-ware platform. The stories would mix both the technical needs such as “Develop a way for the middle-ware components to authenticate to the mainframe components” as well as business capabilities “have the ability to transfer unlimited funds, subject to current available account balances, from one customer owned account to another account owned by the same customer”. The prioritization of the stories would be as follows:

1. Architecturally needed stories such as component to component authentication, high availability, etc. Basically, everything needed to support #2 below.
2. Transactions needed in the new online banking product based on the roll-out schedule.

One of the challenges for this team is the likelihood that the mainframe platform participants are not familiar with Agile practices. Thus, extra coaching is probably a must for this team.

Purchase Content Management Product = I would task the architecture group to work with procurement to select a vendor’s content management product that will become the framework for the new transactional customer user experience. The classic steps would be undertaken: RFI/RFP, product evaluation, proof of concept, vendor pricing negotiations and ultimately product selection. This needs to be completed in enough time for the next team to be able to deliver some functionality in the new CMS product.

New UI Development = Finally, I would spin up another Agile team to map out and build the new transactional UI. Their first challenge would be to reverse engineer the customer authentication system to determine how the system authenticates users and then links them to their accounts and products with the bank. They would need to work closely with the re-branding Agile team to determine the most seamless way to add navigation to the current site to link over to the new site for the real-time transactional capabilities. Additionally, this team would also have to work with the middle-ware team in order to understand the re-usable services being created and how to consume them. Lastly, this team would also have to keep tabs on the content management team to follow the procurement process and start to understand the framework capabilities of the new CMS product and how to link those to the navigational needs and transactional needs of the final online banking product.

This last team would have a heavy architectural staffing up front and transition to a more development heavy staffing towards the end for delivery. In a perfect world, the project management resources from this team would be the most senior in the organization and consistently work with this team as the skill-set transition occurs.

The below Gantt chart reflects the multiple parallel efforts and when they ultimately need to come together to deliver the final product.

The functional roll-outs would be linked to the customer marketing campaign in order to provide sequential customer communication on new product features as well as permit the new technology “kinks” to be addressed. Also, this allows call centers to ramp up temporary staff to address the increased call volume due to the changes impacting customers familiar with the prior system.

The actual sequence would need to be agreed upon by IT, product and call center management, but potentially the following sequence might fly:

1. Launch the old site with the new branding.
2. After a brief window of time to let the call center call volume return to normal levels, replace the link to current “account balance” information in the read-only system to the same “page” in the new system that requests that same balance through the new middle-ware services. The customer experience would be marginally impacted in that instead of seeing yesterday’s balance details they would be seeing their current account balances. Lastly, address any negative performance or functional kinks.
3. Add account transfer links to the old site that take users to the new site to perform the transactions [first real new customer functionality]
4. Same call center pause.
5. Repeat the sequence for additional transactions such as external account-to-account, bill payment, bill presentment, etc.
6. When all transactions are being handled both UI and middle-ware by the new site and the old site is essentially a set of static pages with links, cut the login process over to the new new site and disable the old site when web logs show no stray bookmarked pages are being accessed. Porting over the authentication system was part of the deliverables of the third Agile team.

Sure, this sounds like a full program of interdependent project activities, but from my experience, banks want to provide highly available and reliable services to their online customers which tend to be their highest revenue generating customers as well. Thus, all of the incremental functional roll-outs which come with the additional cost of testing and program management overhead deliver on the risk adverse, reliable and measured change.

I look forward to all the alternative approaches to this challenges Simon has presented. How far am I from the response norm? Any fundamental flaws?

Financial transparency with employees is key to long term success?

As I look back over my almost 20 years of corporate IT employment in multiple MidWestern companies, I’m starting to detect a pattern.  And for those that know me or read my bio know, I’ve working in multiple industries supporting multiple business groups in both public and privately held companies large and small.  Those groups span retail, commodities trading, natural resource exploration, mining and refining, banking and financial services, legal services and manufacturing.  The pattern or trend I am referring to is:

“The degree of success a company or business unit experiences seems to be proportional to the degree of financial transparency reported to employees.”

The more transparent the company or group was with profits or losses, costs and expenditures, revenues and margin, the more successful the company or business unit was growth-wise.  The more secretive and obfuscated the financials the more downward trending the company or business unit as a whole.  I can even recall the same business unit switching from transparent to obfuscated coinciding with a positive to negative growth switch.

The transparency I’ve referring to is not only the quarterly and yearly reports filed with the SEC and available to the investor community.  It is taking some time out of the daily work schedule to bring employees together and explain the business decisions, strategy, budget and market conditions that are behind and driving those numbers.

In recalling my MBA coursework, I had an excellent course on family owned businesses by Ernesto J. Poza, author of “Family Business”.  Ernesto J. Poza is now the Professor of Global Family Enterprise at the Thunderbird School of Global Management.  I believe he also made this link in his course I took at the Weatherhead School of Management at Case Western Reserve University.  His focus was family owned rather than publicly owned businesses, but I believe the theme can be extended to both.  I recently took a continuing education course through Weatherhead and met a CFO of a small, nearby Internet creative design firm who mentioned his company was experiencing measured growth even through the great recession.  He also spoke of the owners having a monthly financial update where a straight review of the prior month’s numbers gives all employees a direct sense of the health of the company.

The straight reporting of the financial health of a company or business unit gives everyone a clear picture of where the company is headed.  If repeated quarters of downward trending financial indicators are given, then no one should be surprised that costs, including employee overhead, needs to be seriously considered for adjustments.  Managing technical teams is more straight forward when everyone on the team knows the health of the overall company or unit.

Can anyone confirm the link between company and/or business unit growth and financial transparent reporting to employees?  Any disagree?

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.

How do you build a strong team?

Some find having to go to work every day … day in and day out … to be a drag, but if you have ever worked on a strong team, you know that that drag isn’t so bad because you have peers around you with a sense of team work that has everyone pitching in to do quality work with a strong sense of pride.  In the previous article I elaborated on elements of a strong team.  This article picks up where that article left off … how does one go about creating a strong team?

How do you know if you are on a strong team?

Simple, you can cite current and frequent examples from your day to day work that align with the elements shared in the previous article.

How does one go about creating a strong team?

A bit harder … up front, a strong team culture, as so often quoted, starts at the top.  The team manager must take steps to foster such a culture.  Micromanaging the team is a sure way to block any sprouting of a sense of strong team.  The manager needs to set the tone that cooperation and teamwork is favored and rewarded with shameless self promotion frowned upon.  Empowerment or more simply, allowing people to do their jobs with low supervision and coaching rather than pointing out failures or frequent “is it done yet?” status queries goes a long way to encourage teamwork.

A team lead or manager also needs to show an outward passion towards the work the team is doing; including taking an interest in what each team member is doing such as listening to what they are getting excited about.  Is it that new development component that enables all kinds of rich UI features?  Is it that next platform upgrade that includes an ability to take a virtual snapshot of a box nightly to aide in troubleshooting those “happens once in awhile, but when it does …” problems?  Is it that emerging architectural standard that will make a great cup of coffee while curing cancer at the same time?  Technical people get excited about aspects of technology that align with their interests.  In leading a team, being aware of professional interests and looking for opportunities to steer those interests toward current and future service demands will help to create a sense of a strong team.  Team members seeing their interests align with work requests will instill a true sense of importance with each individual.  This creates a real notion of “my ideas are being heard and acted upon” and further supports the concept of a strong team described in these articles.

Another opportunity to build a strong sense of team is to try and emphasize a narrow focus for the team’s services.  “We do this, and we do this … of, and we also do this other thing once in awhile” will tend to water down the team’s focus.  In watering down, the team members will see very little overlap in what they are working on with other team members.  With little overlap comes little drive to cross communicate, share items, help solve each others problems, etc.  Sure, a team most likely provides multiple services, but by bringing those disparate services into a more singular and common theme, team members will begin to see how their work overlaps other team member’s work.  With more overlap, team members will be more inclined to share ideas and communicate.  Individuals with technical problems will feel more apt to share since others may have worked on similar issues rather than assume they are a one person silo and will continue to plod along trying to solve the issue on their own.  Also, to reinforce this sharing, as a team manager or lead, try to mix up who is working on what group of tasks.  If Bob is the printer expert, try to avoid routing all printing problems to just Bob.  Not only will Bob grow tired of being the printer guy, he will have no one else to chat with and generate new ideas and approaches to printer problem solving.  Plus, as an added bonus, mixing up the task handling will increase your team’s ability to handing spikes in requests, increasing work throughput, and reducing single points of service failure.

What other external factors develop a strong team?

As a leader, one can try all of the above techniques and achieve some degree of a strong team, but external forces help to bump up the sense of team even further if handled positively.  One external factor that a team led or manager has no real control over but he or she can leverage to their advantage in creating a strong team is having a small team being charged with providing services within a larger organization.  The theme of being the under dog that is struggling to succeed against some difficult odds helps to galvanize a team together with a sense of survival that ultimately builds team work.  This is also colloquially referred to as going up against the 800 pound gorilla.  It is the tried and true notion that working together against the larger “foe” will result in more success than going it alone.  One point of caution, carrying this “us against them” theme too far into a negative tone will work to undermine morale by making people uncomfortable to be pushed to be combative.  Thus, make sure to have a sense of competitive pressure in working within the larger organization but be careful not to proceed into negative territory:

Not OK: “We hate that other team!  They are terrible.  They make our lives miserable.  They can’t plan worth beans and thus everything is a last minute crisis.  They don’t know what they are doing.  We could do their jobs twice as good in half the time …”

Better: “Man that other team is demanding.  They are our most challenging customer.  Since it doesn’t look like they are going to change, what can we do to reduce the last minute crisis requests on our side?”

Another external factor that strengthens a team is going through a demanding work activity involving everyone pulling together to get the job done successfully.  The immediate example that comes to mind is having everyone pitch in together to complete a bunch of tasks for a project that has an aggressive deadline.  By pitching in and completing the work together, everyone shares in completion glory.  Under the tight time pressure, applying the approaches listed prior and acting as a coach or mentor rather than a task or slave driver can give everyone that sense of working together equaled the final success.

Anyone have any other examples of techniques one can use to strengthen a team that one has control over?  How about example of other external situations that, if handled a certain way, can strengthen a team?

Ever work on a strong team?

Do you or have you ever had the opportunity to work on a strong team at any point in your professional career?  A team where everyone has a collective sense of being part of something bigger than themselves?  Everyone had a role on the team that wasn’t defined by a Human Resources job description, but rather, a combination of skill set strengths and work task preferences aligned ultimately with what needed to get accomplished?  A team where, as work came in, everyone volunteered to own tasks and everyone else lined up to provide support and assistance?  A team where everyone knew the strengths and weaknesses of each team member plus everyone could count on each other to get the job done?  If you have, your mind is probably getting flooded with random memories of events and situations of that team environment.  Do affirmative answers to these questions actually define what a strong team means to you?

Strong Team = A team where everyone has a collective sense of being part of something bigger than themselves?

According to research by Amy Wrzesniewski, as reported in 12: The Elements of Great Managing (Wagner and Harter, Gallup Press, 2006), people want to work for an organization with a higher purpose or a mission that means something to them.  I believe the same holds true for a team within an organization.  If a team has each team member working on separate tasks that don’t come back to a common thematic service offering, it is difficult for each team member to get a sense they work for a team with a higher purpose.  Without an opportunity to share related successes and failures and generally kvetch or vent about stressful situations that each team member can identify with, the people on the team won’t have a strong sense of team.  If common exchanges like below aren’t occurring, there doesn’t exist that sense everyone is working for a higher purpose:

Bob: “Hey, working with Larry in Accounting is really a challenge.”

Sally: “Yah, I know.  I dread getting requests from him.”

Bob: “What is his deal anyway?”

Sue: “You guys talking about Larry in Account?”

Bob and Sally: “Yes”

Sue: “Oh, he is easy to work with.”

Bob: “How so?”

Sue: “He just gets very nervous when his PC doesn’t work exactly the same each time.  If you move his icons around or patches or updates cause his PC to work just slightly differently, look out, he is going to freak.  Just let him know nothing is going to change and fix whatever he needs and you will be fine.”

Bob: “Great, I’ll give that a try!”

Strong Team = Everyone had a role on the team that wasn’t defined by a Human Resources job description, but rather, a combination of skill set strengths, work task preferences aligned ultimately with what needs to get accomplished?

Bob might be interested in how the system works together as a whole, and thus engages on tasks that are architecture in nature or involve major system upgrades.  Sally might be a bit intimidated or uncomfortable interacting directly with people outside the team but favors highly detailed technical tasks and thus gravitates towards tasks that fit this description.  Joe might be losing his zeal for highly technical tasks and would rather interact with people to establish the more detailed requirements on what needs to be accomplished and thus provide specifications to Sally.  Sue might be a bit junior and thus gravitates towards the more mundane, repetitive tasks that increases her confidence in her abilities but everyone else see as low challenge work.  Yet, on the HR side, everyone is either a “Systems Engineer I” or “Systems Engineer II”.

Strong Team = A team where, as work came in, everyone volunteered to own tasks and everyone else lined up to provide support and assistance?

Building on that sense of everyone working for something bigger than themselves comes the way incoming work is divvied up amongst the team members.  A sure sign of a weak team is when the team lead or manager has to monitor all in coming work requests, specifically assign out tasks with exhaustive granular detail and follow-up with status meetings and the always dreaded status reports.  At the opposite end of the spectrum is the strong team were as work comes in, everyone assimilates the work without having to wait for their assignments.  Instead of the manager or team leader acting as a task master, instead, they provide guidance as to how to handle competing priorities as well as context behind requests.  This team dynamic involves each team member being aware of their implicit role within the team as well as the strengths, weaknesses and interests of all other team members rather than:

Systems Engineer II: “This work should be assigned to a ‘Systems Engineer I’ and I’ll go back to my desk and surf the web till something fitting my job description comes in.”

Junior resources know the typical IT technical hierarchy where “senior” resources became senior resources by having tenure defined by having rolled up sleeves and made things work to the state the system or service is in at present.  Junior resources know they have to respect this effort and accept more junior tasks until one can grow into a senior resource.  Senior resources know they were once junior at some point and thus are open to assisting fellow teammates.  Junior resources know they need senior resource to help them get their work done; yet, they respect senior resources time and workload and thus only engage after trying all avenues on their own first.  All these combine into a natural divvying up of in coming work requests favoring each person’s unique skill set and interest yet with everyone mindful all the work has to get done on schedule.

How do you know if you are on a strong team?

Simple … you can cite current and frequent examples from your day to day work that align with the elements above.

How does one go about creating a strong team?

Look for part 2 to share some thoughts on how to go about creating a strong team.

Some find having to go to work every day … day in and day out … to be a drag, but if you have ever worked on a strong team, you know that that drag isn’t so bad because you have peers around you with a sense of team work that has everyone pitching in to do quality work with a strong sense of pride.

Anyone have any other examples they can share that captures the elements of working on a strong team?

For both IT managers and engineers alike, it is the least desired activity following a system failure of some kind, coming up with the root cause.  Business and/or product owners outside of IT are waiting, after the dust settles and the system is restored to working condition, to have primarily two questions answered:

1. Why how did the system go down in the first place?
2. What is IT going to do to make sure this doesn’t happen again?

The urgency can return without warning!

The need for answers to these two seemingly straight forward questions generates an urgency that has all the IT stakeholders rallying together in camps.  This series of articles look at this challenging exercise from an engineering management perspective with the first article introducing the “80% accurate technique” and previous article focusing on avoiding the spinning wheel of blame.  This article considers how to approach the inevitable post outage “ruggedization” efforts.

So, you have survived with minor bumps and bruises from a service outage.  The service is now restored.  But does everyone just go about their regular work and forget this grueling event?  Nope … here come the “ruggedization” efforts.  I’ve covered one angle to the project involvement perspective in a previous post.  In summary from that post to set the tone for this extension: “ruggedization” projects tend to have strong support immediately following the outage but as time marches on and new problems and priorities pop up, the “ruggedization” effort loses momentum.  Strong resources move on to the problems of the moment and the challenges of the future leaving weaker resources behind to struggle to move forward on the “ruggedization” effort of the past.  What ultimately puts a nail in the coffin of the “ruggedization” effort is when real capital dollars need approval in order to buy new equipment and/or additional software licenses when many have forgotten the event ever occurred.

Thus you, as a manager, are faced with the strong potential for your team’s resources and your energy to get pulled into this likely to eventually stall out effort.  Walking away from these “ruggedization” efforts initially will brand you and your team as ones that don’t partner with the rest of the organization.  Assigning your top engineers and keeping tabs on all the throws of the ensuring project process could put you at even greater risk of not paying enough attention to new and in flight projects.  Thus you need a strategy to maintain a partnering perception while not losing your strategic focus.

Approach? In a word: balance

Balance in the sense that you need to balance you and your team’s involvement in the effort with the priority the rest of the organization is applying to the effort.  In the beginning, everyone will be running around with a sense of urgency about the effort and you need to be applying an equal amount of urgency.  Everyone external needs to have a similar sense that the urgency they feel is matched by the urgency you and your team export.  But as you get a sense that the organization is beginning to lose the momentum and participants are dropping off to focus on more urgent matters, begin to echo that same level of decreasing involvement.  Depending on your risk tolerance level, you can immediately start pulling back at the sign the others are doing the same.  I prefer a slightly more risk adverse approach.  I have found you get an even more concrete sense of the dissipating urgency as you directly interact with people that were demanding licensing costs, hardware estimates and testing schedules yesterday, but when you follow up with them with more questions today, they noticeably baulk at returning your calls, emails and IMs.  Plus, with this approach, if something goes wrong and everyone is brought back up to the level of urgency (example: system shows signs of potential doom and gloom again), you have a steady flow of “pre-tasks” (introduced in this article) you can reference that has “you” waiting on “them”.  These “pre-tasks” help both with your interactions with external parties and your management.  As they rush to get back into the hyper –urgent state and begin to thrash you and your team with requests, you have immediate responses that redirect them back to their world allowing you to more calming ramp backup.  The same applies to your management as they hear things are picking back up, they want/need a sense that you and your team are on top of the situation.  Nothing conveys that message as when, as you are fighting the current fires and this old fire flares back up, you have this at the ready:

“The customer service quality team is asking where the “ruggedization” project is at?  Well, we are waiting on a quote for the two different server config options the platform team recommended to add capacity from IT procurement.  We have questions out to the enterprise support team for them to confirm what data they are looking to pull from the system logs that they said don’t have the info they need.  And finally, we are waiting on Testing Services to provide a performance testing window to test if the vendor recommended performance tuning settings will have any effect.  So, we are ready to re-engage, but right now, we are waiting on these items in order to proceed.”

Want to be even more proactive?  Then email each of the contacts in the above example and check in on how they are progressing with your request as soon as you get wind the fire has re-ignited.  Then you can add the following to you response to your management:

“In addition, I’ve ping-ed each of those groups to see if they need anything from us at this point.”

This further solidifies you are on top of the situation when you can respond with this vote of confidence.

Thus, in summary, by keeping a pulse on the level of involvement and urgency of external stakeholders and metering you and your team’s involvement to a similar level you can maintain a sense of partnership with the rest of the organization.  In addition, if you are positioned with “pre-tasks” and an at-the-ready response to your management when the “ruggedization” effort goes from cool to cold to instantly hot again, you will respond to their desire to have confidence and trust that you are on top of the situation.  Maintaining both achieves the required sense of balance to maintain the appropriate level of involvement in the “ruggedization” effort along with not neglecting the new and emerging request for attention.