Get over being afraid of our shadow

Some good tips on this article:

How to get the most out of a small IT staff
http://www.mrc-productivity.com/blog/2013/02/how-to-get-the-most-out-of-a-small-it-staff/

• Use web apps
• Give them the right tools
• Choose vendors wisely
• Empower end users
• Move what you can to the cloud
• Know your team

What can IT management learn from Parkour?

What? You have not heard of Parkour? It is a free running style sport that you can see in action on YouTube (youtu.be/WEeqHj3Nj2c). Also, check out the Parkour episode on Fight Science (youtu.be/RBNaiNnNRfU). A short summary is Parkour devotees create an awareness and nimbleness that allows quick fluid movements over uneven urban terrain.
Parkour has three takeaways that can be applied to leading an IT team:

• There are no obstacles, only objects used to achieve an objective
• Decrease shocks and distribute forces
• Conserve energy and release it at the right time

There are no obstacles, only objects used to achieve an objective. A friend of mine who practices Parkour talks about raising an understanding about environment, and transitioning from seeing only obstacles to seeing only opportunities. I like that approach. The transition begins by pausing after anything happens and asking, how can this further our objective, build our brand, improve our services?

Decrease shocks and distribute forces. It is fair to say that not everything that happens to an IT team or on an IT infrastructure is positive. So what do you do then? In the Fight Science clip, Ryan Doyle jumps fourteen feet and then lands in such a way that he dissipates the force. The resulting impact on Doyle’s body is “similar to what a normal person feels doing jumping jacks.” IT teams can and should build systems and processes that are likewise capable of dissipating political and technical impacts.

Conserve energy and release it at the right time. Parkour experts can leap across several lanes of traffic. IT leaders can fund, execute, and secure large scale IT projects. The commonality? Both build energy, save it, and release it at just the right moment. Of course, in IT, that energy is measured by political capital, brag bags, team’s skill sets, potential cost saving ideas, and so on. The trick is knowing when and how to use this energy.

Sure, we may not look as impressive when carrying out an IT project as Ryan Doyle or Daniel Ilabaca. Still, I see a lot of Parkour in the IT leaders that I know. It is the CISO who rolls the right during an outage, thus dissipating the forces on the organization and the security team. It is the guy who leverages an outage to build a business continuity program. It is the manager who cuts the budget at just the right time to obtain funding for a new business critical initiative. I see it all the time. Applying these three simple lessons improves IT.

I had the conversation a few times on Friday. You know the one. The one techies always have when they are with techies. The one where you are wrong and they are ready to tell you why.

Yep. I had a few conversations. What is better, Hyper-V or VMware? Azure or Amazon? DerbyCon or GrrCon? Following Rafal Los or not? *

I answered in my typical measured fashion. Take GrrCon, for example. I like promoting local talent. I like Chris and Jaime Payne. I am speaking there, as are a number of my friends. GrrCon was good to me last year and I am looking forward to returning this year. That is my bias.

“Wow,” the guy who asked remarked, “I’ve never heard someone explicitly tell me they were biased and then only say why they are making a decision. Usually people just tell me what they think I should do.”

That is telling, isn’t it?

My approach to the conversation is simple. I will tell you why I made my decision. If you would like, I can enumerate my reasons behind it. And when my reasons change, my decision will change. I see no reason to get my ego wrapped up in a decision.

So let me tell you why you are right. You are right because you weighed the evidence. You are right because you took into account your strengths and weaknesses, and the strengths and weaknesses of your team. You are right because you compared features and benefits. You are right because you made a choice based on the culture of your organization and industry. You are right because you made a decision that was right for you.

You are right. Now you made a decision that was different from mine. Why not tell me a bit more about what you decided?

Wolfgang

* Footnote: None of these were as vicious as the Linux versus Windows conversations of old. But it struck me as an odd progression. We used to argue over operating systems and chips. Today we argue over virtualization and cloud. That is progress, I suppose. But why are we arguing over places and people? It seems like a strange turn of events.

Many books talk about the diffusion of innovation and the division of the population into a bell curve of innovators, early adopters, early majority, late majority, and laggards. A person in the innovators or early adopters category, some books suggest, will have the latest television, be the first to get the newest mobile telephones, and be up to date on the latest and greatest products.

I have a Panasonic tube television manufactured in the nineties. My phone is a BlackBerry Storm. I am sorry to say that my iPad is gen 1 and still has iOS 4. And yet, many people remark on how innovative my team is with technology. So what gives?

In a word: focus.

IT management needs to be sharply focused on their value proposition. Mine is delivering technology at the nexus of business value, team passion, and team skill. The value proposition effectively splits a team into eight states. On the low side, a particular area can be anywhere between low value, low passion, low skills and high value, high passion, and high skills.

Focus innovative thinking on only areas that drive high value. This takes discipline. I would like more than anything to tinker with a new phone, try out a new iOS, maybe write an app or two. However, we deal with finite resources and limited time. By conserving energy for areas that really drive value, we can be more innovative in ways that are more effective.

Below are the value proposition and the corresponding diffusion of innovation.

1.  Low value, low passion, low skills. Laggard: put in the least amount of resources.
2. Low value, low passion, high skills. Late majority: how can we meet this need by practicing our skills?
3. Low value, high passion, low skills. Late majority: how can we scratch the itch and satisfy the need?
4. Low value, high passion, high skills. Early majority: we have the interest and know-how. Use it.
5. High value, low passion, low skills. Early majority: partner but move quickly.
6. High value, low passion, high skills. Early adopter: create excitement thru being innovative.
7. High value, high passion, low skills. Early majority: be a fast follower to build skills.
8. High value, high passion, high skills. Innovators: give the process your full attention.

InfoWorld recognized my team’s efforts this month with a Technology Leadership Award. This was largely based on the strides we have made since consolidating the application development team with my network operations team. You can view the piece here and on my press page.

I was not contacted for the piece and was rather surprised to see it come across in my news feeds. It is important to add a bit of context to the story, I think.

First, as with any overnight success, the story was years in the making. I met my firm’s Director back in 1998 when I was a project manager at a VAR. It was clear then that they were years ahead of the competition. That advantage never waivered. Under the Director’s guidance, the technology remained on the leading edge year after year. I joined the firm in 2005 and inherited a well-tuned infrastructure with excellent business and vendor relations. This award truly is the continuation of more than a decade of technological leadership.

Second, information systems is a team sport. I am fortunate to have a fantastic team with deep technical skills and broad business skills. The article talks about my role in leading the DevOps (“one team, one system”) and private cloud (“not a cloud in the sky”) initiatives. Both initiatives were developed with a great deal of input from the team. Both were executed successfully in large part due to the team’s prowess. Frankly, leadership is not that hard when you are surrounded by awesome people.

I appreciate InfoWorld recognizing our efforts over the past two years. The Technology Leadership award is reflective of the people I work with. The award reflects their skills, passions, and commitment to the team’s success. Here’s to teamwork!

The BSides Chicago career panel generated a fair amount of buzz. The Rats and Rogues podcast brought members of the panel back for a reunion tour. The call featured Nick Donarski (@kizz_my_anthia), Todd Haverkos, Elizabeth Martin (@elizmmartin), and was moderated by Michael (@SecurityMoey). They invited me to join and share a hiring manager’s perspective. You can listen to the career panel here, and I’ve listed some thoughts below.

First, starting your own business remains a strong way to launch a career path. I mentioned the startup I did in my late teens and early twenties, where we served non-profits for free to build technical know-how and social contacts. Nick Donarski shared a similar experience. He started his own information security business at 17. Nick invested in training and used certifications “to leverage to get business. At the client side, the client also used [certifications] as a metric.”

The panel did revisit the certification question. Chris J came out strongly in favor of “use it or lose it”, mentioning that many paper CCNA certified techs could not even describe a subnet in a standard hiring review process. There was sense that some certification bodies may not be policing their ranks as well as they should. I mentioned “vote Wim Remes” as a rallying call, because I believe that people who feel the certification process should get involved. Remes joined the ISC2 board to raise the value of the CISSP. Todd Haverkos, too, sets a good example by participating on the LPT board.

“Education, Education, Education,” that was Elizabeth Martin’s take-away. Elizabeth drew an fascinating comparison between compliance and certification. In both, it is easier to meet the letter of the rules than it is to meet the spirit. Certification not about getting a couple letters after your name. It is about lifetime education that coincides with and is in support of your career path.

But what happens if your career path does not align with your organization’s needs? It comes down to negotiating with your management. Michael: “We are talking about having difficult conversations with you and your manager. The approach I have taken as of late is to be completely honest and transparent. And I don’t think anyone could ever fault you for that.” With a nod to BSides Chicago’s slogan this year, have these conversations early, have these conversations often.

Elizabeth Martin added: “It is the employer’s responsibility to provide you with the opportunities, the tools, and the training. It is up to you to set the path.” She recommended setting 10 year plans with milestones at 1, 3, 5, and 7 year marks. You can always change plans, but only if you have a plan.

We wrapped up the conversation talking about ways to build the next generation of information security professionals. Mentorship works and we are discussed ways to foster that within the local community. It takes a full commitment from all parties. As Todd put it, “In addition to us doing a better job mentoring and creating people, don’t sit idly by. You get what you go for.”

Such mentorship programs, too, should address the entire lifecycle of employment; from hiring to career changes. Then, Elizabeth and Michael took the wraps off a new project: the Mock InfoSec Job Board. Here, hiring managers can host interviews and help candidates hone their skills.

It was a good 90-minute chat and my brief summary does not do it justice. You can listen to the panel here at Rats and Rogues.

Key take-aways:

• Certification is only one metric of many; consider the candidate’s experience and aptitude to get a broader perspective.
• Volunteer with certification organizations if you are unhappy with the certification process.
• Maintain alignment with your reports and with your managers by having regular conversations about career paths and goals.
• Find ways to build up the next generation of information technology and information security professionals by volunteering in your local area.
• People looking to practice their interview skills should check out the Mock InfoSec Job Board, and hiring managers looking to build the next generation should consider volunteering.

In the run up to BSides Detroit, one of the speakers pitched his talk as learning the table stakes of Linux security. This was new term for one of our younger organizers, and the organizer’s question had me thinking of blogging on it.

Table stakes in poker is the minimum amount needed to be in the game. In business, table stakes is often used as a metaphor for the minimum amount needed to enter a market. Jeff Reich (@jnreich) referred to table stakes as the minimum security required in a system on the Down the Security Rabbithole podcast. Since then, more folks have been referring to infosec table stakes.

Now it is helpful to understand technology table stakes. What is the bare minimum that a business expects from the information systems department? Maybe things like back office applications, email, Internet connectivity, and so forth. What expectations are value-add? Line-of-business apps, hopefully, along with services that differentiate one business from another in a given market.

For most any company, there will be many more systems than there are people to secure and operate them. That is the nature of technology today. The trick is to know what systems are table stakes and what systems are differentiators. Once we know that, we can automate, outsource, and minimize the time spent on table stakes. We can then align the team with the differentiators and spend the majority of the time driving business value.

This is in response to an article by Klint Finley (@klintron):Devs vs. Ops: Sushi vs. Meat and Potatoes.

“J. Wolfgang Goerlich … led his IT ops team to adopt agile operations practices before the Dev team adopted agile development practices.”

My DevOps story is a bit of an exception, stemming from a two year lead up to the team integration.

My organization first made the shift from traditional IT to highly virtualized and highly automated IT. From there, we made the shift to private Infrastructure-as-a-Service IT. The transition entailed high degree of infrastructure rationalization. This put tremendous strain on the network operations staff. We could not take a waterfall project approach to implementing these changes.

From 2008 to 2010, the team became good at agile. We got good at change, and continuous change, and repeatable change, and seamless non-impact change. We changed things daily. On a good day, the community noticed and appreciated the change. On a typical day, the change went unnoticed. On a bad day, the change broke something. And we learned how to quickly and quietly recover and fix things. It was very much a DevOps success story without the Dev.

We addressed that in mid-2010 when the application development folks joined our team. Their organization was still very much projected and followed the standard waterfall model. Cycle times were long and rework was high. Technical debt was also high, stemming from ten years of ad hoc projects in a variety of languages and on a variety of systems. We integrated the two teams and began a process of software rationalization.

“Are there any less obvious solutions to the Dev/Ops divide?”

A successful DevOps team works from the same playbook, has a shared understanding of the system, and is measured by the same metrics.

A core component of this is cross training. Developers, who have been very successful at adding functionality, need to step up their game on providing operational excellence. Operations, who have been very successful at up-time and response, need to step up on providing a service to the organization. My team regularly holds knowledge sharing meetings where a person explains their latest work in terms of the impact to the business and the requirements from the system.

The next integration point is support. My team integrated support on the front-end through one telephone support hotline, and one support email address, and one ticketing system. One person from development and one person from operations are on-call at all times. This creates a partnership when responding to incidents and implementing new functionality.

To complement these integration points, a single set of metrics are applied to both development and operations. The metrics track features delivered, rework, and up-time. This encourages development to adopt rugged techniques. (See the Rugged Software Manifesto, which perfectly captures our mentality towards new code.) The metrics also encourages network operations to deliver new features via configuring existing software.

In the end, our “one team, one system” approach addressed the divide by improving the team’s shared skill-set and by measuring both specialties with a common set of metrics.

“I am pro training and pro certification.” That is about all I had time to say during a career panel discussion at BSides Chicago. Let’s flesh out a little detail on the blog.

First, training is an integral component of being professional. Professional sports stars don’t just show up for games. We need practice to win. We need sustained practice, organized practice, and practice outside of our normal day-to-day duties. That is the only way to know exactly what to do before doing it.

Second, training increases productivity. By dovetailing training with active projects, people can train and immediately apply what they learn. In a positive feedback loop, people’s experiences then drive the focus of the training.

Third, managers with training programs need metrics. Obvious metrics are productivity (changes per x) and quality (failed changes over successful changes). Perhaps less obvious, certifications are ideal because the metric is widely accepted, unbiased, universal, and requires little managerial overhead.

Certifications by themselves can be worthless. However, certifications with experience are invaluable. At the panel, someone brought up the saying that “certifications simply mean you worked for a company with a training budget.” By combining job duties with job training and certification, a person can build one heck of a strong technical talent.

Elizabeth Martin (@elizmmartin), one of the panelists, adds: “I agree completely with all of your above comments. One thing I failed to communicate in the panel is the value of the education associated with certifications. If we view certifications in the spirit of their intent as opposed to the letter (e.g. the letters after your name) there is tremendous value in actually learning.”

Regards,

Wolfgang

Post script: BSides Chicago was amazing. If you have a BSides event in your area, I strongly recommend you check it out. BSides Detroit is coming this June.