Fostering Growth & Innovation In a Sea of Business Requirements
Is there a model or best practice a business can use that provides opportunities for their software engineers to innovate a product or grow their individual skill sets, adding value to a company, without compromising business goals or reducing the velocity of a team? In this article, we will endeavor to answer this complex question by;
- Taking a brief look into common values shared by many engineers
- Reviewing a prior policy once held as the gold standard
- Proposing a multifaceted solution which can be emulated entirely or granularly
The Drive to Learn
While we all have very diverse backgrounds and origins, most software engineers share a common thread — a voracious passion for learning and growing with an ever evolving development landscape. Stack Overflow’s 2017 Developer Survey found that an astonishing 90% of respondents labeled themselves as self-taught, wholly or partially, while half of the same group held a computer science degree. Apple, Twitter, Square, Instagram and Tumblr, to name of a few companies, all have prominent entrepreneurs who are self-taught.
For the self-taught, how we learn has changed. 20 years ago, the maturation of programming languages was brisk. However, keeping pace was manageable and usually accomplished by reading books. Some of those books are quintessential reading even today, like Design Patterns: Elements of Reusable Object-Oriented Software (1st Edition, November 1994). While others … don’t be ashamed of that copy of Professional PHP Programming (December 1999) gathering dust on your shelf.
Now, with sites like Pluralsight, Egghead.io, Code School, or Stack Overflow, which do a fantastic job of creating online training courses that help augment our ability to absorb new coding techniques and specifications or forums for sharing knowledge and asking questions, learning has become more accessible and timely with the exponential growth of programming languages.
The trick, of course, is trying to accomplish this while finding that sweet spot between a work / life balance. For myself, working a full time job, raising a family with three daughters, training for marathons and maintaining a small co-op farm is especially challenging. An ideal scenario could encompass both continued skills growth outside of work and a model adopted by an employer which augments that growth while providing value to their organization.
80/20 Rule - Innovation Panacea or Flight of Fancy
Early on, and even now depending on your employer, the job rarely offered the opportunity to grow one’s skills or innovate with the ever persistent march to the requirements drum to deliver projects on time and on budget.
That changed when Google introduced the famous 80/20 policy, in the mid 2000's, allowing engineers to create, grow, and innovate. This policy, often considered a best practice in the tech industry and various other companies, was heavily duplicated. By 2013, the policy at Google was being effectively shut down. What was the impetus for that shift and are those companies who adopted it now suddenly wrong?
The questions themselves are not easily answered. Creating a culture that allows the freedom to work on “anything” for one day out of a work week (20%) or carving out time for continued education is extraordinarily difficult in a corporate environment when revenue and deadlines are always looming. Furthermore, it introduces a level of risk and uncertainty into an enterprise which can be unacceptable — particularly in public sectors, like health care, where there is a direct effect on human lives.
On the other hand, this sanctioned “time for innovation” provides a magnificent opportunity to allow for exploration and growth. Additionally, it can help establish a scalable rhythm for large and distributed organizations. An excellent example of the success which can be derived from this time is, of course, Gmail.
Is there a middle ground? Can we have our cake and eat it, too? The bottom line: there is no right / wrong solution or best practice that everyone should follow. Every practical implementation is going to be unique, as is the case with another work pattern that shares a similar problem, Agile software development. (We’ll save that gem for another time.)
Taking a Crack at the Monolith
Private and public companies alike, and even various organizations within a single company, have tried to crack the monolith of innovation and employee growth weighed against the needs of a business. Our specific organization provides user experiences for both web browsers, responsively, and native apps found on a variety of devices from phones to connected devices like AppleTV. As such, the focus was creating a pattern tightly coupled to that of a tech organization.
As a Technical Manager of the Client Engineering team at Discovery Digital Media, researching and applying a process of continued learning and innovation that worked for our shop was a challenge but a worthwhile endeavor. The end result was a pattern composed of several key components:
- First, and perhaps most importantly, establishing buy-in from the executive team and business managers on processes for encouraging innovation and personal growth which occasionally will reduce team velocity.
- Enabling innovation through an additional, well-groomed, backlog of tech debt only. Each debt must provide an appreciable benefit to our business and “do no harm” to our user experience(s).
- Creating avenues for personal growth via pair programming and temporary, functionally disciplined, team jumping.
- Lastly, as a manager, understanding your employees and knowing exactly what excites them or the growth path they would like to walk.
A Simple Approach — Employee Management
A solid approach, and the easiest to implement, in creating an environment that fosters employee growth and innovative ideas is to hold discussions with direct reports. This can be accomplished with regular manager and employee one-on-one or bi-weekly discussions and manager and direct report group forums. The key to understanding what drives an employee is simple: listen and reaffirm with follow up questions. Having that knowledge can help steer the types of stories, features, or bugs an employee works on that can dovetail to their interests.
This is not to say that learning an employee’s needs somehow creates a blissful harmony between work and engineer which is absolute. TL;DR, it’s not. Some work, like integrating poorly documented software into an application, just needs to get done. Sometimes the sheer volume of priorities can induce a subconscious state of panic following a common rhythmic pattern of ebb and flow. Irrespective of the work, understanding an employee provides moments of symmetry between work and interest that can go for miles and maintain good morale.
Nurturing Employee Growth
There are myriad paths which can be taken to foster the trajectory of growth for a software engineer. Successful approaches derive from a core understanding of their interests — the basic approach.
Let’s start with the adage, “Two heads are better than one.” This idea is the foundation of pair programming — an agile software development technique. Pair programming at its core consists of two engineers of similar expertise with two functions, a driver and reviewer. In this setup, the bouncing of ideas and discussion is the bridge for growth. Moreover, the business benefits as a result of higher quality code production.
This technique can also be extended in another way where the pair consists of a subject matter expert (SME) and novice engineer. While this form of pairing shares some benefits of the common form, the focus is more on teaching.
Another option, for companies that have functionally organized teams (for instance, a UX team might primarily be developing in JavaScript whereas a services team might be coding in Go), involves the temporary transition of an engineer from one team to another team of interest. Assuming sprint durations of two weeks, and after some planning, the transition could last from two sprints (one month) to six sprints (one quarter).
The primary benefit of this approach is the skill set growth of the engineer who expressed the interest. Further, but to a lesser degree, is a greater appreciation for that product or the business as a whole, which can also translate into greater efficiency with grooming of new features that require involvement of both functional teams.
Technical Debt For The Innovation Win
Technical debt has a bad reputation that stems from the notion of utilizing “just get’r done” logic versus well thought out patterns of code to accomplish work. By definition, that is technical debt. However, I would argue that this definition does not have to be its entirety.
Traditionally, the task of refactoring existing code is the remedy for tech debt. However, other engineering tasks can be “bucketed” under this umbrella, such as routine maintenance or package updates — time is the nemesis of all code. Taking it even further, tech debt can also encompass both spikes (research) and proofs of concept (POC). Why?
By labeling all of these tasks as technical debt, we provide a mechanism for the business to grasp their importance relative to product needs. We accomplish this with a backlog of stories that are nothing but technical debt work. This backlog is maintained, groomed and prioritized by that functional team’s engineers. But how does this foster innovation?
The genesis of innovative ideas resides somewhere between a challenge to overcome and a drive to explore. As programming languages evolve, new techniques for solving complex problems arise that can provide coding efficiencies, previously not available, that may have a net effect of more performant code. In creating a technical debt task, like a proof of concept, we provide a pathway for an engineer to explore those techniques with the caveat that the task must have well defined parameters and demonstrate an appreciable benefit to the product.
With our primers in place, during the ceremony of planning, we work with the business to take stories from both backlogs to define our sprint. Depending on the tech debt task, that focus can be a few hours to an entire sprint plus.
The overall outcome is a product that benefits from routine enhancements and engineers that are engaged, learning and happy.
Buy-In
The above approaches are all academic, without buy-in from an organization’s business owners or executive team. How do I do that?
Promises, and I don’t mean the JavaScript variety.
Start small, start simple and build upon those bits to create a paradigm which works best for your organization.
