Most of us have heard of (or read about) the idea – give engineers the latitude to explore and some free time, and they will come up with great innovations.
However, very few organizations are truly implementing it, and even fewer are harnessing the benefits from it. Yes, there are a few unicorns out there… mostly located on the other coast.
My personal experience has been with organizations where some lip service was paid and even some effort was made, but without any tangible outcome – the excitement fizzled out and died quickly to be replaced by the next SVP initiative.
Why is it so difficult to make work something that sounds so simple?
There might be a number of reasons:
Lack of time – most organizations I know work at 120% capacity. The most talented and intellectually curious engineers are usually the ones swamped with the most work, fixing the inefficiencies of the system as a whole. It doesn’t help when the boss says “take Friday afternoon to innovate” when the engineers have a long list of bugs or incidents they must address ASAP – usually after hours or over the weekend. Innovation does require some peace of mind and slack time so that the mind can wander a little, build new synapses and reach that “Eureka!” moment.
Lack of leadership– while innovation cannot thrive in a highly centralized, top-down organization, it still needs some degree of shepherding and shared vision. The object of innovation needs to have a purpose that is aligned with the overall mission of the organization. The role of the leadership is to set that vision, frame the challenge that needs to be solved and nurture the innovation sapling until it is ready to take a life of its own.
Culture – “innovation” cannot be bolted on. It has to be incubated and deeply embedded in the DNA of the company. An “innovation program” cannot thrive in a command-and-control organization, with entrenched leadership and a rigid performance evaluation and reward system that is solely based on numbers and dollar figures. The entire organization needs to value open-mindedness, risk-taking, and failure tolerance. The performance appraisal system needs to include intangible factors to reflect ingenuity, brilliance, and non-conformity that may not be immediately translatable to bottom-line figures.
“If a tree falls in the forest, but there is no one to hear it” – too many brilliant ideas die out because no one champions them and takes them beyond the engineer’s workstation. Once an innovative idea sprouts, the organization has to have a path forward and a plan for how to assess and evaluate the idea, and if determined worthy – invest in it, harden and propagate so that it can be used by others.
“Friday” itself – it may be circumstantial, but presently every other Friday is the End of the Sprint – the team has ceremonies most of the day, and at the end, they are way too exhausted to do anything creative. Not so circumstantially, Friday is also the day people usually cut short, take off before long weekends, or mysteriously fall sick (“Fatigue Fridays” seem more befitting).
Working in government contracting poses its own challenges – small and mid-size organizations tend to be very projectized. Each individual project has its own client and project performance objectives. Development platforms, processes, tools, and team organization are generally dictated by the client organization’s policies, procedures and comfort level, and they may vary significantly. Project managers are, generally, in full authority of their program resources and naturally, protective of them. Each project is its own silo. At the same time, we as systems integrators, are constantly challenged by the federal clients to bring new and innovative solutions to the bids, while operating at rock-bottom margins.
To work around the challenges at my last corporate job, I implemented an alternative to “innovation Fridays”. I formed a separate team consisting of members from various programs. We wrote a 1-page document (I can share offline) that serves as our charter, manifesto and team rules all in one. We posted it on our wiki site as a reference to old and new team members. We evaluated and normed on a set of tools we’d use to plan and track our work (Jira), document and share knowledge (Confluence), and collaborate (Slack). We created a cloud (AWS) sandbox environment completely fire-walled from the rest of the corporate network and assets, where we could run, experiment and demolish penalty-free. The rest is a slight modification of the Scrumban process:
The Product Owner (yours truly) is responsible for identifying the new learning objectives tied to the development of strategic new corporate capabilities (Epics – e.g. “Create a demo-ready pipeline running on OpenShift”). The PO works with the team to break down the epics onto more atomic and tangible user stories and tasks (e.g. “Complete O.S. online introductory class”, “Install Dev O.S. cluster”, “Create a sample container and deploy it on the cluster”). She grooms the backlog and sets priorities depending on what upcoming demos or bids the company needs get ready for. The Scrum Master facilitates the working sessions, maintains the Story Board to be accurate and in sync, negotiates with the team their availability, and helps clear any roadblocks. The team is formed on a voluntary basis. All team members are self-motivated, self-organized and fully committed to their primary projects, but very excited to work on the cutting edge with this group. The team is fully empowered to add new tasks to the backlog (e.g. new frameworks they want to explore, new tools, more automation for certain tasks, etc.) as well as to define their availability.The team meets once per week for 4 hours, usually on Wednesday or Thursday afternoon. (The time-box is negotiated with the respective PMs and resource line managers to ensure no client priorities will be adversely impacted.) The 4 hours are time-boxed as follows: 20 min Scrum and status update from the past week, 20 min demos of completed work,20 planning for the next batch of tasks that are ready to be picked up. (Team members have the option to pick up a task and or opt out of it.)160 min of collaborative work – this is the time for the engineers to work on their own tasks and collaborate with their teammates on any dependencies or blockers. 20 min Scrum – a recap of what was accomplished during the working session and what remains to be worked on offline. Generally, everyone picks up some work they may have to work on offline before the next weekly working session. Each teammate decides what their best-effort commitment is based on expected workload from their day-job projects. At the end of the session, we also decide on the schedule for the next session. We try to stick to a fixed schedule and a steady rhythm, but client commitments always take precedence.
Exercising this approach of semi-structured, purpose-driven learning, we were able to:
strike a balance between structure and flexibility, build new solutions and corporate capabilities while still meeting our contractual obligations and without burning out our engineers with forced overtime.upgrade the skill set of our engineers with minimal $$ investment in training, create a cross-project/client-silo collaboration and a culture of knowledge sharing and innovation.improve morale and enlist more volunteers who also wanted to join the fun squad (Our team name was literally the DevOpsSquad).
Within 3 months, we built a small prototype of a containerized microservice application on a commercial cloud, demonstrating a NIST (Moderate) - compliant cloud architecture and a fully automated CI/CD pipeline – quite the engineering achievement for a team that was stuck with mundane O&M work on a legacy monolith application.
One may argue whether the above is “innovation” or just another engineering project. The bottom line is that we started with a blank slate. We invested mostly time, energy and intellectual curiosity and a little bit of overhead expense for the AWS account. And we created something that eventually led to a $1.7M contract extension and numerous additional benefits.
(revised 9/12/18)
Bella Trenkova