In the People/Process/Technology construct, I believe that process, particularly process that is aligned with empowering, organizing, and adapting to eliminate the impediments of your people is the next critical aspect that needs attention.
Increasingly, and certainly for startups whose principal value is captured in the intellectual capacity or capital of its people, effective development and organizational process is critical to applying that brainpower to the problems that your company is out there trying to solve.
So, ask yourself, are you maximizing the intellectual abilities of your team? Are you engaging and challenging them to contribute, or are they being invited to stop thinking and just do what's handed down from on high?
Are you at risk of having your policies and procedures resulting in having your employees stop thinking, stop trying to find a better way, and to stop asking insightful questions? If you’re using process to introduce handcuffs, consider why?
There may be good reasons to institute oppressive or onerous policy decisions. Maybe you've inherited or hired the wrong people. Or you can't or shouldn't trust your people to know well enough to do the right thing. Or perhaps the risks you face too are great (from a regulatory, legal, or economic perspective)?
Even for the most conservative of organizations, these elements can be changed as part of company culture through proper one-on-one mentoring, encouraging empowered teams, and in drastic situations, through personnel changes.
Ultimately, I believe every technology manager's goal can be summed up as the "three E's":
- Educate (your people)
- Eliminate (their impediments)
- Emancipate (Set them free to do the same across your organization)
There are a lot of ways to do this, and I don't want to be evangelical about how this must come about. Some of you will be able to do it in waterfall organizations. Personally, I have found that embracing Agile methodologies (in my case, Scrum) both adheres to the right things, as well as introduces a significant enough change to warrant re-evaluation by your team members of "the way things are and if things should continue in that way".
Inspired by the LEAN school of management pioneered by Toyota, Agile methodologies like Scrum and Kanban have evolved the art of software engineering to be more predictable, and towards more collaborative team-oriented development on short iterations called “sprints”.
In a nutshell, and in contrast to the traditional "waterfall" approach of development, instead of long, drawn-out, and unpredictable development death-marches, where the deliverables are big payloads with big risk, agile adopts 1-3 week dev iterations, that tend to represent much more knowable, much more manageable cycles.
Because cycles happen quickly, teams have a lot of time to practice design, development, testing, integration, deployment. In my organization this happens nearly every single week, meaning we are challenged constantly to improve the status quo in all of these dimensions.
You've heard the adages that "practice makes perfect". I've been in an organization where launching a product took upwards of a year. If your launch team only launches one major product in one year, are we surprised that they get rusty in developing code that is production ready? On the other hand, if your team launches code to production dozens of times a year, who's more likely going to be able to launch dozens of times a day?
Long before Agile and Scrum were even coined as development methodologies, Tom DeMarco and Timothy Lister in the excellent book "Peopleware, Productive Projects & Teams" summarized one of the benefits of iterative development:
“The chemistry-building manager takes pains to divide the work into pieces and makes sure that each piece has some substantive demonstration of its own completion.
Such a manager may contrive to deliver a product in twenty versions, even though two are sufficient for upper management and the user...
Each new version is an opportunity for closure. Team members get warmed up as the moment approaches, they sprint near the very end. They get a high from success. It suffuses them with renewed energy for the next step. It makes them feel closer together.”
Tom DeMarco & Timothy Lister, PeopleWare, 1987
Beyond the concept of "sprints" in agile development methodologies, Agile advocates having clear strategic vision from the top of the organization, to "stratical" mid-term roadmap planning, to the tactical mechanics of day to day standups and sprint planning meetings.
The most critical aspect to agile methodologies, in my humble opinion, however, is the power of the retrospective. Not only does Agile focus on removal of impediments, tackling problems collaboratively, and providing transparency to the challenges and triumphs of tackling your commitments, but it provides an avenue for people to express endless curiosity and continuous team and self improvement.
My friends have coined a term called "Khanalogy" for my penchant to use analogies to explain sometimes mundane concepts. So I'll share a Khanalogy with you now...
What would you rather be-- a business organism that has no auto-immune response... an organism that can't recognize threats to its resources, its capabilities and its long-term survival.... Or an organism that recognizes when things aren't going well? One that detects problems, assumes responsibility for fixing them, asks for help when required, and brings the appropriate (and sometimes full) force of that organization's prowess to utterly decimating the impediments that afflict that organism?
Do you want to micromanage this behavior, like a drill sergeant rousing its unfit cadets out of their slumber to react to a threat, or do you want an autonomous system that can spring into action like an elite special ops team like the secret service protecting the president?
If your team isn't full of people who are motivated, empowered, and willing to engage the problems and impediments preventing them from becoming a world-class engineering organization, properly implemented Agile methodologies may represent a set of tools that could kick that into high gear.
In Part 3, I tackle the technology dimension of the trilemma.
