Software has eaten the world. And as it continues to consume new and diverse industries it’s transforming the way business is done. We are all in the “software business” now, regardless of the product or service we provide, forcing us to reexamine how we structure and manage our organizations.
When I ask managers if their organizations practice “agile” they almost always say yes. Probing a bit deeper reveals that most of this agility starts and ends with the product development teams – specifically software engineering. There is rarely a mention of “agile in the HR group” or “continuous improvement in finance.” And yet, it is in these infrastructural disciplines that agility must take root to support software-driven businesses.
As the nature of software continues to shift towards continuous delivery, we are able to create a new type of conversation with the marketplace – a continuous one. We deploy products, observe, measure, interview, learn, and optimize in hours, not months. Decisions are made quickly. Directions shift overnight. To support this rapid, iterative optimization of our business the internal organizations that staff, fund, manage, and reward our people need to exhibit that same level of agility. “The way we’ve always done it” starts to put the management tier in direct conflict with the potential of the execution teams.
Let’s take a look at HR first. The object around which most HR organizations operate is the job requisition. A traditional job requisition is usually nothing more than a list of tools and capabilities buffered by ambiguous language about “self-starters” and “team players.” These job descriptions are written to fill a gap in a discipline-specific silo (e.g., the software engineering team or the design team). Recruiters, incentivized to fill roles quickly, scour resumes for these skillsets ensuring that anything that makes it through to the next round has “ticked all the boxes.” Three years of Rails? Check. GitHub? Check. Candidates are passed on to hiring managers who are then pressured to make a decision – ensuring the HR teams hit their time-to-fill quotas.
This style of hiring doesn’t build organizational agility. Quite the contrary, it reinforces the barriers between disciplines and minimizes cooperation. Instead, HR teams need to start hiring for creativity, collaboration and curiosity. They need to seek out the non-conformists — the candidates that don’t easily fit into a box. These are the generalists with an entrepreneurial spirit. They’re the multi-faceted tinkerers who have specialized in a discipline like design but turn out to be pretty good coders. They’re the skeptical members of the team. The ones always pushing back on the status quo and forcing the business to rethink the way it presents itself to its customers. New hiring practices have to be put into places to attract these candidates. Interview structures and exercises have to be completely rethought. It’s nearly impossible to assess a candidate’s collaboration skills in a one-hour Q&A. What do we need to change in order to learn if this new candidate is the innovator that will push our company forward? How do we ensure that our hiring practices continue to improve as the nature of our business evolves?
If we’re hiring ever-curious, entrepreneurial team members, the next logical question is how do we incentivize and retain them? In the past, we’d just assign them to a team; give them a project to build and if they shipped on time and on budget (or at least close enough to it) they got rewarded in some way. That’s not enough anymore. Financial compensation is not the main motivator for these folks. Building something meaningful, something they can call their own holds much more value. Is there a way for us to rethink compensation structures to include equity (or at least upside) for the ideas our collaborative teams create?
Project funding is another monolith that must conform to our new reality. CFO’s want to know what will ship in return for funding an initiative. While there is never a shortage of answers (you are trying to get funded after all), the true answer is rarely given – we don’t know. There is an ambiguity in software development that renders the end state unknowable. Unpredictable levels of complexity, market turmoil, and shifts in customer behavior put any product roadmap longer than four to six weeks at a high risk of quickly becoming an outdated artifact.