Cross-Pollinating Productivity

What can we learn from going outside our industry and examining how folks in very different fields get things done? I’m starting to think that the answer is: quite a bit.

It's common to talk about breakdowns in communication and workflow within an organization. If sales isn’t talking to the product team, for example, the sales team won’t really know what they’re selling. If marketing isn’t talking to the programs team, the marketing materials won’t be aligned with what the organization is actually doing.

It's less common to talk about the siloing between industries. But what if we did intentionally cross-pollinate lessons learned from one field to the next? I think there’s a lot to learn from that practice, especially if we’re searching for ways to refresh and optimize our productivity.

Last week, I got to see my good friend Blake deliver a keynote to a couple hundred software engineers at his company. He’s a senior engineer who has been there since almost the beginning, so he knows of what he speaks. And even though I was one of the only, if not the only, non engineer in the room, I derived a ton of value from his talk. I will be better at my job moving forward because of what he shared at that keynote, even though I was far from the target audience.

His assertion was that the craft and creativity of those engineers is needed now more than ever. While that may hit home in a particular way for software engineers in the age of AI (then again, now that Google AI is recommending we put glue on pizza, perhaps our concerns should melt away), there's wide applicability to that thesis. It's not just engineers who could benefit from creativity.

Hiya! If ya like what you're reading, why not forward to a friend and subscribe for a short post every Tuesday morning?

Blake laid out five principles. I'll list those principles below, along with my own summary and reaction to help demonstrate the value I derived from listening to a talk that wasn't intended for me.

1. Do a large volume of work, even if it's bad
   He was essentially saying that you simply can't expect to produce high-quality, creative work if you are so paralyzed that you don't create a bunch of stuff to begin with. That seems to me to be applicable to just about everybody who creates anything of any type. I certainly feel that. Sometimes ya just gotta start doing the thing, putting aside the concern that the thing you're doing won't be good enough.
2. Always keep your feedback loops tight
   As you create, seek ample feedback along the way. Otherwise you can get too far down the path and realize you have created something that no one asked for or will use. This point really hit home for me, as I've thrown myself into some pretty lengthy projects recently that have benefited from tight feedback loops that clearly improved the end product. We spent a good chunk of last year building our strategic plan, which was refined by stakeholder feedback throughout the entire process. That made the end plan much better.
3. Go one level below your current abstraction level
   Ask yourself what's happening below the surface, and examine if there's something important happening at that level that you could develop expertise in. I really like this frame of reference, and it's something I haven't paid adequate attention to. In the context of the work I do, I'm now wondering what I should be learning about higher education that heavily influences the more specific veteran-in-higher-ed work I'm immersed in.
4. Focus on work that compounds
   Projects and work don't happen in isolation, and as you iterate, you will have more robust end products. This resonates with something I've been thinking and writing about lately regarding how we can build knowledge in college and beyond. Knowledge itself compounds, and our ability to learn, comprehend, and the number increases exponentially the more that we learn, comprehend, and remember.
5. Work on things you might fail in
   Lady Jessica may believe that fear is the mind killer (man oh man was Dune 2 a good flick), but my friend made a compelling case that fear doesn't have to necessarily be a bad thing. The challenge is when you let it take charge. It's okay, and indeed necessary, to take risks and be willing to fail. Couldn't agree more. This has been one of the biggest growth areas for me as a leader over the last few years.

The applicability of these principles to my own work is clear, but I never would have thought about things like this had I not gone to this event. I simply don't understand things in the same way a software engineer would. Speaking of things I don't understand, you can read up on some of Blake's work here.

There is value, I believe, in intentionally pursuing this type of cross-pollination. From a productivity standpoint, it can be super helpful to learn how professionals in a completely different industry get things done. That could be the type of thing that spurs innovation and builds meaningful perspective. In terms of identity, cross-pollination can foster genuine reflection on the similarities and differences with professionals in other industries.

Exploring practices outside of your immediate field-of-view might feel scary. It also might feel counterproductive, as it's a less linear way to get the things on your existing task list done. But with a wider, more fulsome perspective, the work product you deliver will end up being more effective and nuanced. It'll, if you will, be more three-dimensional, which matters more and more in a world with a penchant for flattening.

Now if you'll excuse me, I'm off to do a large volume of work, most of which will almost certainly be bad.

---

p.s. Here's the AI-generated image WordPress suggested I use for this post. I, uh, disagree.