I had an article, Five Ways to Use DevOps to Capture Innovation, Engage Your Employees and Delight Your Customers, published on the CA Technology Exchange.
I discuss how digital, mobile and bring-your-own trends are impacting customer, partner and employee technology expectations in unexpected ways. I look at these trends through an unusual lens to better understand how to respond to software eating their industry.
As a result of the article, I’ve had some good internal conversations that I feel are interesting to share.
Q: When are employees going to be able to write code inside of our already lean 40-plus-hour workweek?
A: Many companies talk about 10 percent or 20 percent time for “side projects.” Other companies provide educational opportunities, where they might offer a learning management system with programming courses. Why not have exercises based on real stuff? Other companies may use it as an opportunity to socialize, like with hackathons. Some companies do this already.
My personal opinion is that people are quite motivated to do their best work. These “side projects” will be powerful because people will be motivated by “doing their best work” to accomplish them. I was never a programmer, but I majorly tricked out Excel early in my career to give me the productivity of three while improving compliance. I’m sure I’m not alone.
Q: How do full-time developers take to the idea of unofficial employee app developers? Are they supportive of this idea?
No! They think I’m crazy. In fact, I just had a conversation on Facebook defending my perspective. The counterpoint is that even professional programmers don’t write code well, so how can non-professionals?
I see it as a long adoption curve (say 10 years) but people are getting more and more programming literate. They expect to be able to use their technical skills to solve their own problems. It’s anecdotal now, but I’m certain it’s a trend.
Q: What impact do employee-developers have on the business? I imagine there is potential for significant distraction away from the employee’s core business function.
A: Maybe. But there is also the potential to capture a lot of innovation. I would argue it’s better than people starting their own businesses on the side. I’d also argue that they’re working around IT anyways … so might as well figure out how to bring them into the fold instead of pretend they’re not there.
Q: I’m curious what percentage of employee developers would actually complete the development of a useful application. I’m guessing this number would be low given not all employee developers have strong app development acumen?
A: Maybe. But a few counterpoints … People don’t always finish things, but they learn from them. Also, people finish things today — whether it’s working with an unsupported SaaS solution or creating a complex spreadsheet that gets adopted by the department, or simply writing scripts to get their job done. There are a ton of department-level databases out there, or SharePoints, none of which connect to anything else and are ungoverned by IT. There’s a lot of stuff going on that IT doesn’t control. The risk is growing, and they need to control it.
I believe that companies can adopt an open source model to keep projects ongoing over time with dynamic teams. I also believe they could use transparency provided by collaborative development tools and incorporate people’s results into their reviews, promotions and future responsibilities.
Q: Who decides if an app that an employee develops passes or fails specific tests?
A: That would be IT, though I’d hope a lot of it would be automated. The model is similar to a public app store. The app store sets guidelines, provides developers with tools and a platform, but ultimately it’s the app store review process (run by IT) that defines how applications are approved.