Midwest IT Survival

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.

Project sponsor turnover can be handled smoothly

Hallway conversations and whispers in meetings have the grapevine quickly communicating the departure of a highly visible person in the corporation. “Did you hear Bob gave his two week notice?” “Yah, any idea where he is going?” “No, I don’t think he shared that.” “Who is going to lead the big FlimFlam upgrade project now?” “Don’t know that either. It hasn’t been announced. Bob has been it for as long as anyone can remember.” “This could get very messy.”

I was reflecting on my participation in a large, multi-track, multi-phase, multi-year project some time ago. So, safe to say, this was a big project involving substantial change across a variety of technology groups, products and business units. About a third of the way through the project, the day to day business sponsor left the organization for an outside opportunity. Since the project was well under way, being a third completed, a new sponsor was needed to step in quickly to keep providing direction to all the concurrent work streams.

Executive Leadership Steps In

The executive sponsor immediately started attending the regular program level status meetings. This provided much needed leadership. Thus, two big thumbs up for her participation. Instead of everyone looking around the table at each other wondering who was in charge, there was continuity in project leadership.

New Sponsor Arrives

The executive sponsor didn’t waste much time sourcing a new business sponsor for the project. With only a few weeks of drift, a new day to day sponsor was at the table. The executive sponsor gave a brief introduction and the new sponsor took charge. Following the introduction, it was clear to everyone that the new sponsor wasted no time getting up to speed even though he had no prior knowledge of the project nor subject matter expertise in the goals and objects of the project itself. The new sponsor already had had meetings with key stakeholders individually.

New Sponsor Sets the Tone

The new sponsor also gave brief summary of the current state of the project, the major open issues and summarized the strategic next steps. In summarizing the next steps, the new sponsor established an immediate credibility as the prior sponsor seemed to be struggling a bit with how to prioritize the cross-functional team’s focus for the in-flight work streams. All in all, the new sponsor, in the first formal meeting, established a strong confidence that had everyone leaving that meeting with a positive sense of enthusiasm that we were all in good hands for the remaining work ahead. The new sponsor clearly set the tone for project success.

So what made this potentially negative situation result in a re-energizer to the project team?

• Executive leadership presence immediately upon word the current sponsor was leaving the organization.
• Executive leadership remaining visible and actively engaged through naming the new sponsor.
• The new sponsor’s strong initial engagement and clear understanding of:
  • Project’s current state
  • Clarity surrounding open issues
  • Ability to articulate next steps.

Has anyone else experienced a positive project sponsor change? What contributed to the success of the leadership switch?

Just code a secure "app" for banking, right?

If you are inundated by the seemingly constant barrage of news surrounding people clamoring to get their hands on the lightest, thinest, most powerful mobile phone or tablet, you might be wondering: With all of that consumer demand, how come, if my bank even has a mobile application, why can’t I do all the things I already do on-line? Well, I’ve been digging deep into mobile device security capabilities lately and have a good appreciation of why the gap in functionality exists … and for good reason.

I’ve written before about the challenges of delivering banking functionality like moving money around on-line before here and here with the focus being your, now, classic web browser based Internet banking. Fundamentally, the interaction between a web browser and your bank via the Internet is essentially the exchange of text. There isn’t much programmatic logic running on your pc, laptop or even mobile phone/tablet with web browser based banking. Thus, there isn’t much one can do as an attacker except manipulate that text going back/forth. Assuming basic security measures are in place, short of stealing someones full credentials, there isn’t much opportunity for a big score for attackers. Of course, there are always exceptions.

So, what makes mobile device security such a big deal; isn’t it just Internet banking from your phone?

In short, a program or “app” that is given to the end user to install and run on their device is a huge difference from a security perspective.

Your initial reaction might be: big deal, just build a secure “app” and off you go!

Well, it seems that “building a secure app” isn’t quite as easy as it should be.

Short of the RIM Blackberry mobile platform, mobile devices are currently being built as 100% consumer focused, enable all functionality easily, devices. RIM has been the market leader in corporate managed mobile devices through their “Blackberry Enterprise Server” or BES software you install in your company. It acts as the great security gate keeper between all managed RIM devices, their configuration and what data they can and can’t access. Lose your Blackberry? The BES software can remotely wipe the phone of anything user or company specific the next time the phone is turned on. Want to specify what “apps” can be installed on a Blackberry? Just have the BES software forcibly un-install “apps” that aren’t on the approved list. To top it off, all communications between the various Blackberries and the BES software is encrypted without the end user being able to disable it.

This approach involving communication with a central security provider coupled with stronger on device data access protections has made the Blackberry the obvious corporate solution for security minded companies. It is too bad that RIM hasn’t found a way to enhance their device’s user experience as all other device platforms appear to be eclipsing RIM in that regard. The flexibility your iPhone, Android, WebOS and Windows device has in allowing end users to have nearly 100% control over device level functions means the expectation that a user hasn’t somehow disabled or manipulated or even installed malicious software (knowingly or unknowingly) is completely non-existent. Add in “jailbreaking” where even basic end user constraints are removed from a device and it is next to impossible to be assured a device is in any configuration baseline let alone “secure”. Sure, web browsers can have vulnerabilities as well as malicious plug-ins installed, malware, etc., but there exists some ways to detect that a users “device” has materially changed enough to engage in additional levels of authentication. More on this additional authentication later in this article.

So, what plausible options exist?

First, from a security perspective, if there is no way to completely know a device is “secure” (whatever that means), then one has to assume the device is “un-secure”.

This means one has to expect that any “app” deployed on a phone is completely vulnerable to attack.

Thus, any thought of storing any information, such as a password or even a user name to help save typing for logging in to a bank system is out of the question. Anything that the “app” creates for some security purpose also can’t be trusted. Thus, generating any unique device identifiers or user identifiers needs to be assumed compromise-able. Even trying to re-use the current on-line “device profiling” security technique where unique, seemingly, non-changing device attributes (like OS levels, browser versions, video and audio hardware configurations, etc.) are used to link a human to their device accessing their bank data isn’t available today on mobile devices.

The security concept in “device profiling” is that if you are logging in from a “known” or “registered” device, then there is a stronger likelihood it is the same user compared to a user that was logging in from a “known” or “registered” device for the last umpteenth logins but now is logging in from a new device. In this new “device” scenario, the ability to ask the user knowledge or challenge questions or send an email or SMS message with a one-time password helps to further determine who the user really is. Mobile devices currently don’t allow “apps” to gather such “device profiling” data from the device. The positive for privacy fans becomes a negative for legitimate uses of such device identifiable information such as banks.

The data, like a device or SIM card serial number, which is not programmatically accessible to marketers or other folks looking to track your device and your where abouts is also now not available to banks which could use this to aid in the customer authentication process. Example explicit technical discussions confirming this challenge on the Andriod platform here.

Lastly, the growing/mainstream typical “out of band” mechanisms for authenticating on-line users is leveraging the user’s mobile device. Need an extra factor to authenticate a user on-line? Send a random 8 digit number as an SMS message to their phone. Then, if the user attempting access on-line can type in that 8 digit number in a reasonable amount of time, it is more likely the user and not someone else. A banking “app” is already running on the user’s phone, so any phone call, email or SMS text message to that user would arrive on their … phone. Thus, so much for that additional useful authentication factor.

Thus, with in-secure devices running end user manipulatable applications without a strong mechanism to tie a user to their device programmatically, it is going to take some significant improvements of any kind in order for the functionality one enjoys interacting with their bank on-line to be matched feature to feature on mobile devices in the near future.