Thoughts on training after BSides Chicago

“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.

Story telling is a key component of managing and marketing an internal IT team. At least, so I have recently come to realize.

How does one market their internal security team? That question was posed to me by Steven Fox recently. Steven is a good friend and he is working on a book. I was hoping to help him, but I was not quite sure how to answer the question. I pushed back. I don’t really think of what I do as branding. But Steven pushed back too, and we got into a great discussion.

I am a firm believer in the power of a good story. Stories can promote the strengths of your team. Cautionary stories of other firms’ failures can help position your team for success. The right anecdote to the right person at the right time is a powerful thing.

I had not thought of this as marketing. But Steven helped me see it in a different light. Story telling provides consistent messaging that helps build a team’s reputation.

Here are some tips on story telling for IT managers:

1. You are story teller rather than the focus of the story. Your team members are the heroes.
2. Keep it real, keep it honest, keep it positive.
3. Maintain a story book or clippings folder for internal success stories and failure stories.
4. Maintain a story book or clippings folder for external stories, particularly
5. Share these stories with your team as well as your stakeholders. A good story celebrating a team member’s accomplishments needs to be shared.

Have a good story? Drop me an email or catch up with me on Twitter.

Wolfgang

Post script: Steven Fox recommended I check out the All Marketers book by Seth Godin.

How often have you heard the following? “I am thinking outside the box here, and if we only had this budget we could make it work.” Or how about this? “I am thinking outside the box but I keep getting shutdown because of the people around here.”

Thinking outside of the box has become synonymous with wishful thinking.

It is great to be different, to be unconventional, and to tackle problems from new perspectives. The box, however, is very real. There are budget constraints. There are time constraints. Possible solutions must make sense to the people who will make the idea a reality. Claiming to “think outside the box” while bemoaning a lack of progress is ineffective.

I say, think inside the box. Come up with creative solutions that incorporate as much of what we know about the industry, the organization, the teams, the people. Come up with creative solutions that we can afford, and solutions that we have the time to implement. Leverage the close relationship you have as an internal IT person to make solutions that outperform those that anyone else could do.

First, think inside the box. Then, understanding the box, we can get creative.

Scope, schedule, and budget. Perhaps no other concept is as deeply driven into the heads of young project managers. It is the iron triangle. The triple constraint. Scope, schedule, and budget define project quality.
However, the iron triangle fails for in-house DevOps teams.

Consider the following scenario. An employee needs a simple AR aging report. Such reports have been around forever, so the scope is tightly defined. The development team comes in and specs the project. They say two weeks. The project manager promises three weeks. The project comes in at two and a half and produces a flawless AR report. In scope, on time, and on budget. That is a success, right?

Now fast forward a few months. Support gets a call that the aging report is blank. But accounting knows that there are old invoices. Clearly, something has gone wrong with the report. Support starts digging into the problem. There is little to no documentation. Hours are wasted trying to ferret out the logic of the reporting process. It turns out to be a simple error in the inputs, something that could have been caught with some defensive programming. Hours more are spent in addressing the source data.

The actual but perceived quality of any deliverable varies over time. The AR aging report was a success on day one. But it was a failure when it was blank a few months later. Assuming the underlying issue does not get resolved (ie, the code bug lingers in input validation), the problem will continue to periodically occur. Come a year or two down the road, the business owner will complain that the aging report is junk and a new project will be started.

In this scenario, we have a simple logic flaw. Worse, assume the program was written without any security controls. Now all someone has to do is insert a check request in the unprotected source data, and create a fraudulent check. Though well within the iron triangle, such an aging report will contain operational and security concerns.

In the beginning, a project manager or a team manager can score a number of successes by strictly meeting the triple constraint. Each success, however, adds to team’s technical debt. I have seen many teams fail because of such successes.

With separate teams, such debt is someone else’s problem. The development manager has a string of successes while the operations manager is spending increasing amounts of time tracking down glitches. With a DevOps team, such debt is everyone’s problem. This means developers end up spending most of their time troubleshooting and patching old code. Development efforts slow because of this friction. Pretty soon, the business is wondering why it takes so long to get anything done.The solution? First, for in-house development efforts, cost is fixed. We are going to pay our folks regardless if they spend most of their time in support or most of their time on new functionality. Schedules are flexible and can be driven by the team. And scope, scope must explicitly include quality aspects driven by operations and security. That is to say, the project must be secure, it must be sound, it must be supportable, and it must meet the business owner’s needs.

Looking back at the AR aging report scenario, I would propose the following. Take the developer’s original estimates. Include estimates for code review. Include time for security review, and for hammer testing the application. Include time for documentation and other meta tasks. Perhaps that now boosts the time for the report from three weeks to six weeks. The project manager may not score a quick win. However, over the lifetime of the report, the business will see this report as more reliable and as higher quality. Further, over time, fewer hours will be required to support broken software. More time will become available for implementing new functionality. Build new functionality to a high standard and we create a positive feedback loop. That loop is key to delivering sustained business value.

Delivering sustained business value requires thinking outside the triangle.