Posts by John Proffitt

I don’t really like talking about my flair

Photo Friday: Mom at Apple 2012

mom-at-apple

My mother has been a huge fan of Apple for decades, so back in 2012 we visited the famous 1 Infinite Loop in Cupertino. She even made a contact that got her, me, Dad, and my wife into Caffe Macs for lunch, after we shopped for Apple swag at the Company Store.

My mother is partially retiring in June, after she turns 80! Meanwhile my father is also working full time, after turning 80 last year. They are either fantastic examples of hard work or terrible examples of retirement. I’m proud of them either way.

Email is a weapon sitting on your desk, pointed at you, ready to be used by anyone

Great piece in The Atlantic today about email. It goes through the history of email (back to the 1970s) and then hits the highlights of the EFail hack announced a couple weeks ago.

One choice quote on email encryption systems:

OpenPGP is hard to use, and S/MIME can only be maintained by IT departments. These tools were never popular, will never be popular, and don’t even encrypt most of the metadata leaked by email.

And another quote, this time on how email is fundamentally flawed:

The lesson of EFail is that you can build everything well, but if you’ve built on a bad foundation, there’s no structure strong enough to stand.

It’s a great piece for techies to share with non-tech colleagues that want to understand a bit more about why email is the most dangerous attack vector for most users today.

https://www.theatlantic.com/technology/archive/2018/05/email-is-dangerous/560780/

Photo Friday: Borrego Springs Sea Serpent

IMG_0170.jpg

Apparently 2012 was a big travel year for me. Here’s a favorite photo from a trip in November of that year when my wife and I spent time in Borrego Springs in the middle of the Anza-Borrego Desert State Park (part of the Sonoran desert). Nearby is a big collection of massive metal sculptures created by artist Ricardo Breceda. This one is the Sea Serpent, but there are many more. Head out to southern California to see the installations for yourself. Beautiful spot. Just visit in the cooler months!

Photo Friday: Kilauea 2011

kilauea-2011

As an earth science nerd, I was excited to see Hawaii in early 2011. The wife and I skipped over Honolulu and the popular beaches and made a bee-line to the Big Island, where Kilauea had been erupting since 1983 and you could see some of the newest land on the planet. Given the recent movement of magma downslope to the Leilani Estates area, I’ve been transfixed — half excited, half horrified — by daily video updates showing the ah-ah pushing down neighborhood streets and vents shooting lava into the air with the roar of a sulfur dioxide jet engine.

This photo is from a quieter time when the lava lake was snuggled deep inside a small crater at the bottom of the much larger Hale Ma’uma’u crater at Kilauea’s summit. While staying nearby in Volcano, Hawaii we ventured out to the visitor center at night, perched on the edge of the crater, and saw the distant, eerie glow of the steam and ash drifting up from the liquid rocks.

To help residents affected by the lava movement into the Puna district, check out the options listed in this article from Hawaii local TV station KHON.

And stay on top of all the Kilauea earth science news from the USGS here.

How to tell when a vendor is walking away from their product or service

I recently discovered I’m clairvoyant.

Okay, not really. But I did realize I can tell when a vendor is walking away from a product or service and my company will be left holding a threadbare bag. Which got me thinking: Could I come up with a list of warning signs to share with colleagues, and are there more warning signs they might share with me? I’ve got 5 listed below, but if you have more, I want to hear them.

1. They sell the product (but not to you)

The first warning sign: a vendor sells their product — or whole business — to another company. In the best case, maybe support and development is a bit of a mess for a while, but then things are fine or maybe even get better. For example, Meraki was sold to Cisco in late 2012 and as a happy Meraki customer (and a Cisco critic) it made me really nervous. But Cisco kept their paws off Meraki and their products and services are at least as good as they were before.

In contrast, look at a product like NetBackup. In the olden days NetBackup was owned by the original Veritas. It grew in popularity and spread across the enterprise backup space. Then Veritas was bought by Symantec (strike 1). But Symantec management changed strategies and dumped NetBackup and other products into a reconstituted Veritas (strike 2). Finally the new Veritas was picked up by a private equity group in the hopes of making money from the big installed base (strike 3).

But during the years while NetBackup was being passed around (always to the left), it wasn’t growing or changing much. The venerable NetBackup languished in a market filling up with innovators like Veeam and Commvault. By the time the private equity guys were in charge, it was too late. NetBackup was outmoded and all the backup software development talent and energy had moved on.

Today, Veritas is a company that, in my opinion, is run by a group trying to maximize profits from the installed customer base. They may also be trying to spruce up the company for a final sale. It’s a pretty sound strategy for them, but not a great plan for your company. Watch your back when your favorite product is bought or sold.

2a. You can’t understand the support guys anymore

pexels-photo-256219.jpegAre you a software shop that wants to make money right now? Just ship your support operation overseas where labor costs far, far less! Not only will you cut your expenses and boost quarterly profits instantly, but your customers won’t figure it out immediately. Besides, once they do figure it out, they won’t go through the pain of moving to a new product for at least a couple budget cycles. But by then you’ll have cashed in the stock options and moved on to your fancy new job.

I recently found out the hard way this had happened to a managed firewall service I inherited from predecessors. It was a mediocre service on a good day and on a bad day it could make you pull your hair out. But (but!) if you had problems you could call support and you got native English speakers that understood the tech and could help you manage it, despite the inherent challenges.

Not anymore.

Just last week I discovered support had moved to southeast Asia, and not just to follow the sun. Though no one would dare admit it, it’s pretty clear the provider figured out the service didn’t stand a chance against focused managed security providers, so they put it on cheap-labor life support. Too bad they did that right after they spent a lot of money building their custom Flash-based web interface (Flash in 2017? D’oh!).

I’m dumping that service this year but in the meantime, I get the classic support runaround where they force you to sit through scripted troubleshooting steps that aren’t relevant to my issues. And bonus: they lack knowledge of, or access to, any other part of the provider’s global infrastructure, despite the services having deep interdependencies. Yeesh.

2b. There’s only 1 support guy left

Hat tip to Will Duderstadt, who noted this option over on LinkedIn. An alternative to support being shipped overseas for cheaper labor is just to cut support to a fraction of its former strength. Technically, you’re fulfilling the terms of your contract (you’re offering support), and so long as there isn’t a Service Level Agreement (SLA) in place, you’re home free. And even if there is an SLA, customers will have a hard time getting compensation for broken SLAs. So again, by the time the customers figure it out and move on, you’re long gone.

I suppose the Daily Double in this case would be support getting shipped overseas and cut back to a fraction of the people needed. (Sounds like some kind of ancient Celtic curse.)

3. The last new feature appeared during the Bush administration (either one)

pen-idea-bulb-paper.jpgThis is a variation on number 1, but in this case, the company making a product you love just isn’t putting any more wood behind the arrow (so to speak) — the product is not evolving with your needs or keeping up with competitors. While the functionality of the core product is still solid, the grass is getting greener in everyone’s yard but yours.

The “EMC” part of Dell is my favorite example here. Like most giant corporations they have, at times, been slow to adapt to trends and like any big, successful company they can struggle to innovate (the Innovator’s Dilemma in practice). In this case, we all know the story: spinning-disk storage reached enterprise maturity, but flash storage players like Nimble, Pure, and the rest showed up. The new entrants were a great fit for many kinds of customers, so they beat EMC not only with SSD speeds, but with innovative software layers that enabled new storage and virtualization functionalities. Sure, EMC picked up companies and tech to compete along the way, and at this point they’ve effectively got feature parity when you consider their full line of products. But how many customers did they lose on the way to catching up?

If you’re the IT manager on what is becoming a legacy platform, plan for either a mass upgrade to the new platform your legacy provider acquired, or plan to move to a faster-moving entrant. (NetBackup vs. Veeam works here, too.)

4. The ink on your sales rep’s business cards never dries

pexels-photo-326576.jpeg

This one I’ve seen in the telecom space perhaps more than anywhere else. Indeed, I used to work with a carrier in Alaska where my sales rep would change 1 or 2 times per year. That’s an extreme example, but anytime the sales staff changes, ask some questions — it might be for structural reasons that signal waning support for the service or product you’ve come to rely upon. And if the sales team changes repeatedly, get nervous.

Good salespeople — the successful ones — know when the product they’re selling isn’t competitive and is getting squeezed by new players. They decamp to greener pastures. That said, a sales rep or sales team change doesn’t necessarily mean the service or product you’re buying is going away. But keep your eyes peeled.

5. Company X buys Company Y to get Technology Z, but they already have Technology Z!

pexels-photo-277124.jpegI’m looking at you, Cisco. And you, too, Dell.

IT manufacturers need to grow and innovate, and in a lot of cases an acquisition is the fastest/easiest way to get that done. But sometimes those acquisitions bring in products similar to products a company already offers. And when that happens, you can bet there will be a fight to the death amongst the product teams, and the product you currently use could be the loser.

Cisco has long been a poster-child for technology development via acquisition. But Dell’s multiple forays into backup software is a favorite example today. At one time in recent years Dell had no less than 3 overlapping backup products under the Dell roof. And then they bought EMC, who had even more. No company is going to take 3, 4, or 5 heavily overlapping products to market indefinitely. Consolidation will happen. But… are you riding the winning horse?

This is why the Cisco Meraki purchase made a lot of people nervous — it’s not like Cisco was missing Wi-Fi, firewall, or switch products! But thankfully Cisco realized they weren’t buying hardware — they were buying into a particular market segment they couldn’t address well, and they were picking up a recurring-revenue subscription service that made Smart Net look outdated.

Are there more?

Are there other warning signs for the decline of a product or a vendor? Add a comment below or drop me a line — I’d love to hear what others have experienced!

Cover photo: Adam Jones / Wikimedia Commons

Photo Friday: Crater Lake 2012

Six years ago my wife and I were in Oregon on vacation, exploring for fun and figuring out where we might like to move if we headed south from Alaska. We made it up to Crater Lake on May 5, 2012 to enjoy the sunshine, deep alpine snow, and the iconic views. We didn’t end up moving to Oregon (we really liked the Bend area) — we ended up in another “O” state instead. But maybe someday.

How to use Kanban to “Lean” into infrastructure projects in an IT consulting shop

I originally posted this on LinkedIn back in June 2016. I’m reposting here because I’d like it to live here on my own blog. Since the original post 2 years ago I’ve changed companies and changed tools. I’ll write an updated article soon.

Back in February 2015 I took on the role of IT Practice Director in an IT consulting shop, leading a team of engineers in providing infrastructure projects and all-around IT outsourcing services for small/medium businesses. And like most businesses in America (by number), we’re small. We don’t have hundreds, let alone thousands, of employees, so we can’t afford to create highly-specialized positions — we all need to wear a lot of hats. For example, it’s not reasonable for us to employ a full-time Project Manager. We could definitely use that kind of help, but we can’t justify the salary and truthfully we couldn’t keep such a person fully engaged or grow their professional skills. Plus, the extra workload from running our projects in a fully PMP-certified manner would increase the cost of our projects, and our clients wouldn’t appreciate it.

dilbertpm

Despite lacking a formal PM, we do IT projects all the time. We migrate clients to Office 365 or other cloud systems. We upgrade servers, storage, virtualization platforms, and networks. We collaborate with outside firms, such as cabling specialists and data center providers like our local favorite, Metro Data Center. More importantly, we often do all those project types simultaneously for multiple clients. In effect, we have our own little PMO (Project Management Office), but there’s no PM calling the shots — just me and some IT engineers.

As you might imagine, it ain’t easy.

The Problem

When you have upwards of 20 projects going simultaneously, usually for just as many clients, simply keeping track of what’s done, not done, and coming up next can make you crazy, not to mention tracking sub-tasks, projected hours, shifting priorities, and the heterogeneous skills of the engineers. Aside from that, we also want to complete our projects so we can… you know… get paid.

Given our situation, we needed a way to solve the following problems:

  • Know what projects (1) are being designed and sold, (2) are starting, (3) are in progress, and (4) are closing or were recently closed, and see all the projects, project phases, clients, and engineers in a unified workflow
  • See where we have resource conflicts so we can design around those situations, but not constrain ourselves to the point where we create gridlock and can’t adjust timelines as priorities shift
  • Display all our work in a visual way that non-engineers can grasp, so we can have meaningful discussions about our work rather than spend most of our time just trying to explain what’s going on to people outside the engineering team
  • Utilize a system biased toward project closure and completion, not sales or project starts (it’s easy to start a project, it’s not easy to finish one)
  • Keep our project management work to a minimum, to save us time and save clients money

We didn’t arrive at our current solution quickly. We went through a few phases along the way, and perhaps what we learned can help your team…

Classic Project Management Solutions (that didn’t work)

To get started with our “lite” project management approach, I turned to everyone’s favorite sortable-text-in-a-grid solution: Microsoft Excel. It’s a great place to get started because you can list everything you’re doing and create more and more cells with various data fields you want to track with each row of data. With automated formatting, you can even color cells and text depending on the contents, making the whole thing easier to grok at a glance.

pmbyexcel

This went along fine for several revisions and a few months. At one point it jumped from Excel to Google Sheets (to make it shareable and simultaneously editable by the whole team). But the job of maintaining it almost always fell to me. So the more detail we added, the harder it was to maintain.

During this period I also tried using a cloud-hosted project management tool I’d used a few times in the past: Smartsheet. It can be simple or complex, it can be private or shared, and it has nice Gantt-style visualizations as well as dependencies between tasks. It’s Microsoft Project for a fraction of the cost and with a lot more collaborative capabilities.

pmbysmartsheet

I ended up using Smartsheet on a big multi-phased project that was hard to manage, but for tracking all our projects it was even harder to manage than Excel. I liked it, but this was a tool that needed at least a part-time PM, and we just didn’t have that available.

By the fall of 2015, project work was picking up and the need to track our tasks individually and as a team was getting urgent. Excel had failed. Smartsheet had failed. Asana didn’t take off, either. And Basecamp, while useful for a lot of collaborative work — we still use it today — just wasn’t designed for multi-project organization and visualization. We were getting bogged down with resource conflicts and project delivery was slowing as the load went up. I needed a new tool, but more importantly, I needed some new methods.

Agile… Scrum… Sprints… Lean…

As an avid reader of IT industry blogs and news, I was well aware of the popularity of current software development methods and buzzwords like Agile and Scrum. I had even introduced the idea of “sprints” during 2015, but lacking other methods, it didn’t take hold. Meanwhile, the literature in the field talking about these new models was focused almost exclusively on software development — which wasn’t really relevant to an infrastructure team.

phoenixprojectI started looking around for books talking about project management using new Agile-ish methods especially in IT infrastructure contexts. I found some books on Amazon, then turned to my Safari Bookshelf subscription to review some of the best examples in detail. That’s when I found The Phoenix Project.

While Phoenix was not a how-to book, I found it a cracking-good read. It’s a (nerdy) novel telling the story of how a DevOps model of work was brought into a fictional corporation’s IT department, and how that transformed (and saved) the business. It rang true to my career experience and it thematically addressed the problems we were experiencing.

Welcome to Kanban

Featured at the center of Phoenix was the application of Kanban, a decades-old Japanese manufacturing operations model, and the theory of constraints. These mental and operational models revitalized the fictional company’s IT function that was mired in competing demands and resource conflicts. I knew I needed to take this to the next step: learn more about Kanban and try out some tools.

I downloaded a few more books via Safari and looked them over, but the turning point was finding a succinct how-to manual from LeanKit: Kanban Roadmap (free via sign-up). The Roadmap explained how to get Kanban started with your team, including terminology, processes, etc. With the Roadmap in hand, I ordered lots of Post-It notes, a big whiteboard, and spent several hours creating project/task sticky notes from our projects spreadsheet.

Our first Kanban board looked like this:

whiteboard1

The new board mapped out our project steps from left to right, covering all our major phases:

  1. Sales opportunities (once they exited from Microsoft Dynamics CRM)
  2. Sales engineering and proposal development
  3. Sales completion
  4. Project preparation, setup, scheduling
  5. Project delivery: Work in Process (WIP)
  6. Project wrap-up and closure

Each sticky note was a project for a client. Colors designated project types. Flags were attached to projects when an engineer was assigned.

We then proceeded to hold weekly stand-up meetings at the board and track project movement, discuss roadblocks, rearrange sticky notes as needed, and more. We didn’t use the daily stand-up recommended for software teams, mostly because the engineers weren’t consistently in the office and it felt like too much of a commitment.

Stuff We Learned

Visualizing all the work and making it “public” in the company was a wild ride at first, and we learned things about our unwritten processes:

  • It became clear Sales and Engineering didn’t see eye-to-eye when it came to whether something was “sold” or not (which is typical). We also didn’t always agree on when developing a formal quote was necessary. After a lot of conversation, we set new standards for each phase of the sales process, and that sped up sales qualification and our quoting.
  • Many projects routinely got stuck in various ways. Some stall-outs were self-inflicted, but a lot were caused by schedules and preferences of clients. We could now “see” when projects got stuck, which allowed us to apply appropriate force to “unstick” them. We couldn’t stop the detours, but we definitely shortened them.
  • We struggled too hard to move projects from “sold” to “started” because we lacked a standard process for kicking off projects and setting dates. We were pleased when a sale was made, but didn’t immediately schedule the work because we were still “busy” delivering previously-sold projects. Seeing this let us shrink the gap between “sold” and “delivered”.
  • Executives and sales folks could now easily see what was on the board at any time. Honestly, everyone was shocked at how many clients, projects, engineers, and other activities were in flight at one time. The Kanban visualization gave us shared context and, despite the flurry of sticky notes, we calmed down individually and as a team. We were finally in control.
  • Kanban is definitely biased toward project completion. At every step, we were collectively working to move project “cards” from left to right. A common language developed: “What will it take to move this card to the right?”

Going Digital: Kanban on LeanKit

leankit1While it was fun (it really was!) and even useful to do our Kanban projects board with sticky notes and markers on a whiteboard, we realized this had one huge down-side: you couldn’t see or edit the board if you weren’t standing in front of it. So if you wanted to update something from your desk, or from a client site, or from home… too bad. This made the board less accurate because we really only updated it weekly. It was also a bit of a pain to edit the sticky notes (you often had to make new ones), and if you ever wanted to edit the lanes on the board (which we did a couple times), it was a major undertaking. Clearly, we needed the board to be digital, and ideally in a collaborative cloud service.

I tried out several Kanban-based online tools, but after each trial I kept drifting back to LeanKit, the source of the Kanban Roadmap. LeanKit turned out to be the best option, so I converted our physical board to LeanKit, shared it with the team, and we were off to the races. We still had weekly meetings, but they were faster because the board was updated all week long. Very quickly I also started making adjustments to the lanes on the board — something I’d avoided with the physical board because it was such a pain. But software changes? No problem!

The central part of our board recently looked like this:

leankit2

We’ve been using LeanKit for several months now, and it’s our go-to project tracker. It’s visual, simple, and shared. It keeps us focused on moving our work forward. We can see where things are working, where work is stuck, when we have conflicts, or when engineers need more work. For us, at our size, but with the complexity of our work and the lack of a dedicated PM, it’s been been a “just right” solution.

One important process change developed recently: we’ve stopped our weekly whole-team meetings. Instead, we do individual engineer meetings on a weekly basis, reviewing status, next steps, and solving problems. The LeanKit board is still visible to everyone, and sometimes project cards jump from engineer to engineer, but we’ve definitely made the review process more personalized.

Up Next: Refine, Repeat

There’s more we could do with LeanKit — there’s a powerful reporting system built-in, and we could load up sub-tasks and sub-boards to break down projects into smaller and smaller bits — but we’ve opted to keep it simple for now. We’re just happy the Excel spreadsheets, Smartsheet plans, Asana to-do lists, and all the rest are gone. We still have too much work to do at any one time, but at least we know the size and shape of the work and we can thoughtfully prioritize better than ever before.

It’s been less than a year with Kanban and LeanKit. No doubt we’ll make more adjustments, and perhaps we’ll try new tools. We may even introduce a daily stand-up, like software teams. But right now, for our team, our clients, and our IT infrastructure projects, we’re doing pretty well.

Got questions? Recommendations? Please drop me a note!