The following is an e-mail I wrote to my managers about 4 years ago when they asked for feedback/ideas on the "cross-pollination" initiative they were planning to launch.
Hi Scott, Joel, Alona, Jenny,
This is several weeks late but I hope it could still be of some value. I have considered going directly to my suggestions/recommendations but I thought it may be worthwhile to also share how I got to them. (This is as much an attempt to organize my thoughts on "cross pollination", learning and knowledge-sharing as it is an attempt to synthesize and share ideas from books and articles I've read recently and not so recently so I hope its tone and length don't turn you off.)
Personally, I think "cross pollination" is a great idea but, as is probably obvious to everyone, doing it effectively is quite daunting because there isn't a simple, straight-forward formula or a sure-fire method to guarantee its success (i.e. that the desired outcome is realized -- a high number of engineers with sufficient retained knowledge to competently work on multiple products.) This, I believe, is because it all boils down to the people or the engineers involved who have varying skills, motivations and capabilities. (The variance is of such magnitude that, according to this
study which is the basis of this
article, the traditional normal or bell curve, which SeaChange continue to use, is ill-suited for characterizing performance distributions in organizations and that the so called power law or curve, which seems to pop up in various areas in human dynamics, is more appropriate.) As such, I consider the following to be key to doing "cross pollination" in our context effectively:
1. Willingness of engineers to learn
2. Their ability to learn quickly
3. Their problem-solving, analytical & critical thinking skills
4. Their sense of (collective) ownership i.e. doing whatever it takes to get the tasks done
5. Hiring the right people to begin with
6. Keeping them motivated to excel
To a significant degree, items 1 - 4, particularly 2 & 3, are pre-determined (which is why I think the importance of 5 & 6 cannot be over emphasized). Some are just innately predisposed, while others are not. (Furthermore, they are hard to measure. How can an engineer's willingness to learn or whether or not he/she has good problem-solving skills be measured. I doubt if any single metric can accurately capture any of these "competencies" but my hope is that there is an identifiable set of KPIs that can effectively measure, if not the "competencies" directly then, the results they are expected to produce.)
However, regardless of innate predispositions, I believe that all four can also be acquired or learned, at least to a certain extent, and that the right organizational culture (shared values, beliefs, mindset & norms) is key to acquiring them (over, say, formal training or rigid processes because these "competencies" like many others require
tacit knowledge that by nature is difficult, if not impossible, to codify.)
Thus, to be successful (with "cross pollination"), I believe we need to create a culture where 1) excellence and learning are valued, 2) collaboration and knowledge-sharing are the norm, 3) challenging/questioning the status quo is encouraged, if not expected, and 4) every team member feels collectively responsible for each of the team's deliverables (or more generally, for the success or failure of the entire organization.) Moreover, I believe that if we are to succeed (in creating such a culture), we ought to expect the process/journey to be messy, difficult, protracted and iterative, fraught with errors and failed experiments (that we nonetheless have to make)
I realize that 1) although these are lofty ideals, they are rather abstract -- what we need are concrete practices; 2) they cannot be achieved overnight or at all, without focused, coordinated effort and constant follow-through; and 3) ultimately, it is the "plumbing" and not the "poetry" that counts -- it's going to be the nitty-gritty, day-to-day implementation that determines our success or failure.
So in this vein, here's my attempt at some raw but concrete (-enough, I hope) recommendations:
1. Institutionalize knowledge sharing
A. Regular (monthly?) half-a-day(?) sessions where engineers share:
a. What their teams are currently doing and why to other teams
b. Challenging problems solved recently and how
c. Demo new product features or share lessons learned from last sprint
e. Other interesting topics they found useful and think will be useful or at least, of interest to other teams (e.g. Java GC, Cassandra internals, performance tuning tools, etc.)
- As introduction/first topic, engineers could discuss/refresh the overview/architecture of products they sustain/develop and how these various products fit together.
- I envision this to be relaxed and informal (more akin to a discussion over dinner rather than a formal training) where engineers can freely discuss and ask questions even remotely tangential to the topic at hand.
- The point being to create linkages or open channels where knowledge can diffuse across teams and product "silos" as well as reduce the learning curve for engineers that will be "cross-pollinated"
- Can't be called "knowlegde-sharing sessions"; catchy name needed
B. Augmented Scrum
- Augment or even just re-focus the 3 traditional scrum questions of "what did i do yesterday?", "what will i do today?", "what issues are blocking me?" with "who did i help yesterday?", "what new concept or technique did i learn yesterday?", "who will i help today?" and "what do i need/want to learn today?"
- The point is for engineers to be always conscious of learning and knowledge-sharing/collaboration as well as recognize their value in relation to their tasks.
- I see cross-pollinated members (or "cross-pollinees") as primary players and beneficiaries of all these "learning and helping".
C. Re-vitalize the Wiki
- I believe our wiki has some very valuable content but is poorly organized. There ought to be a conscious effort at improving its structure and links (between articles/entries even beyond product "silos") and that effort should be considered a "real" task (i.e. managers should recognize/promote that it's worth allocating putting hours into) rather than just a side-task or a filler. Perhaps, techpubs can also help out or even lead this undertaking (i.e. improving organization and linkages of wiki pages).
- Creating wiki pages should be made an essential/integral part of an engineer's workflow, again, rather than just being an after-though or an add-on task or worse a distraction e.g. make it an expected artifact or better, another channel where engineers discuss ideas.
- Managers should start using the wiki too; for meeting minutes, documenting plans, updates, ideas or whatnot
- Naturally, "cross-pollinees" will once again be primary drivers here since they will be doing a lot of learning and should utilize the wiki to take note and organize what they've learned.
D. Debriefing "Cross-pollinees"
- When cross-pollinated members return to his/her original team or transfer to a new team, there must a mechanism/venue/expectation for him/her to share what he/she learned from the team prior, even if it's just an overview of the other team's product or the detailed design of a some very specific component.
2. Encourage, or even force, collaboration
- Design/create user stories in a way that encourage collaboration or even manufacture, instead of avoiding, inter-dependent stories that force engineers within and across teams to collaborate so engineers could learn from each other
- Move away from the mindset that individual engineers are allocated to specific stories/tasks as it naturally fragments the team (with individual engineers pre-occupied with his and only his tasks), instead "assigned" engineers should be seen as leads or primary movers of stories that are collectively owned by the team; the entire team is expected or even required to contribute. Naturally, this implies that a team can't have too many members or too diverse or too many stories at once (if this is the case, then, despite appearances, there isn't actually one but multiple teams.)
- Mentoring/coaching others should not be treated just as a side task to be undertaken when one's schedule allows (and thus something unaccounted and hence, seen as a burden), but a task and a goal in itself with its "cost" (in hours or whatever) and "returns" fully recognized by managers and the team. In other words, it must be made (or made known explicitly to the team that it is) an expected activity/task worth putting hours into and a value in itself.
- A "cross-pollinee" should be assigned, together with an experienced engineer, to an important story in the current sprint, preferably one that requires learning a significant breadth of product knowledge. This setup, especially because the story is important, makes collaboration imperative and in the interest not just of the "cross-pollinee" but of the entire team (because it can potentially make or break the sprint). It is therefore imperative to clarify and constantly re-iterate that though only two engineers are assigned to the story, it is the collective responsibility of the entire team.
3. Supplement story planning/commit meetings with design and strategy meetings
- In practice, the "formal" story planning has been reduced to identifying stories/tasks, high-level estimation and resource allocation i.e. assigning the stories and scheduling release dates.
- A deeper-level discussion doesn't really happen and understandably so, because the information to facilitate such discussions are, more often than not, not yet available at that time and also because during commit meetings coming up with dates and schedules are the primary focus/pre-occupation. (I'm not looking for implementation-level detailed discussion but definitely something deeper than the usual high-level discussion during planning.)
- I believe the best time for such discussions to happen is during follow-on meetings at the point when an engineer is ready to design a solution or come up with a testing strategy.
- This should also provide a venue for analytical/critical discussions that are too long to be accommodated during scrums but too valuable to let slip.
- (And, even as I write this, it seems off to me or it seems to me that the order is somehow backwards -- that estimates and commits come ahead of these more "deeper-level" discussions.)
4. Reward excellence
- Make the process of selecting awardees more objective & transparent; to be truly fair, reward base on merit, instead of trying to spread bonuses "to be fair."
- Identify KPIs and track individual and team performance based on these KPIs; the KPIs themselves need to be carefully selected and under constant review; also, extreme care must be taken so the identified KPIs do not result to the opposite of the desired behavior i.e. engineers becoming too cautious or taking too much risk (and cutting corners as a result) or worse, "gaming" the system (to get high marks on KPIs without actually delivering or even eroding value.)
- Move away from the normal-curve based annual raises; treat performance evaluations as a re-hiring process (e.g. instead of "engineer X got a rating of Y, that puts him/her on the top so-and-so % and so he/she gets Z percent increase", why not "engineer X adds this much value to the team, losing him/her would be a pain; in our industry's job market, he/she would probably get, and so deserves a salary of, A (and not some percentage value based on his current pay.)"
- Come-up with team-centric incentives to reward excellent,highly-collaborative teams; perhaps instead of, or better, on top of individual bonuses, there could be team bonuses; there ought to be some level of "rationalization" or "normalization" though, since not all teams get equal opportunities to "shine".
Thank you for reading all the way through.
-Ronald
