The cross-functional team: Separation of concerns

Working on a cross-functional team is hard!

As specialists, be that specialization in software development, bioinformatics, or molecular biology, we are domain experts; yet, projects still fail to come to fruition on time, on budget and with the expected impact. This is as frustrating and demotivating to the non-technical manager as it is to the specialist team members.

Lets look at a case study…

Kate (software developer) and Darnell (biologist) are hustled into a meeting room by Xue (non-technical manager). In good faith, Darnell (biologist) lays bare his frustrations with the existing software. Kate (developer) records these as a list of requirements. After rubber-stamp approval by Xue (non-technical manager) and two weeks of furious coding, the revised software is ready. Unfortunately for Darnell (biologist), the software is even worse than before.

There is another meeting, with more senior developers and biologists in attendance Kate steps-through the changes she made, and how the changes address the requirements gathered from Darnell. The biologist and developers don’t understand much of each-others technical jargon, but do their best to provide input into Kate’s new requirements. The developers insist that ABI Instruments are used by the biologists because their output format is standardized, and therefore easier to import. The biologist demand that ‘big data’ capabilities are implemented by the developers. All Xue can think about is justifying the expense and deadline slippage to her annoyed higher-ups, along with the sickly feeling of having her neck being breathed down.

Sound familiar?

The organizational problem is that our specialists, Kate and Darnell, are trained to deliver ‘locally’ optimal solutions within their area of expertise; unfortunately, real-world problems are usually ‘global’. The challenge to the cross-functional team is to approximate a reasonable ‘global’ solution with a set of ‘local’ solutions contributed by each specialist. Put another way…”software problems” are few; “problems benefiting from software” are many.

Separation of concerns to the rescue

Separation of concerns (SoC) is a precept of modern software engineering. Focusing on the ‘what’, and abstracting the ‘how’, enables collaborative development on large code-bases, easing maintenance, extension and debugging.

The concept is simple: disparate modules of code must communicate through a common interface. As long as the interface remains intact, the internal workings of each individual module may be modified independently. Importantly, each developer need only know the details of their own module, and the interfaces of the modules they interact with. The concerns (implementation level details) of each module, are thus separated (self-contained, and preferably free-standing).

At first glance, this might not seem particularly relevant to Kate and Darnell, but managing separation of concerns should be a cross-functional team’s #1 tactical priority, second-only to sharing a common vision (#1 strategic priority). Separation of concerns forces our cross-functional team to focus on ‘what’, instead of ‘how’.

For the software engineer, separation of concerns means crafting sensible code modules, with a thoughtful API. For the cross-functional team member, it means understanding the high-level problem (what), coming to a common understanding (interface) with ones peers, making that understanding explicit (‘human API’), and sharing a common language to discuss solutions.

To successfully implement, each team member requires:1

Mutual ownership of the ‘global’ solution.
Gradient awareness of team member capabilities.
Commitment to communication, which includes trust, honesty and good faith.

Re-examining the case study…

Kate (software developer) and Darnell (biologist) are hustled into a meeting room by Xue (non-technical manager). In good faith, Darnell (biologist) lays bare his frusterations with the existing software. Kate (developer) politely stops Darnell (biologist), and asks Darnell and Xue about the actual ‘problem’ they’re trying to solve (mutual ownership). Putting aside specific frustrations with the software, the three discuss each others overall-process and ‘pain-points’, both biological and software (gradient awareness). The three state and adjust their understanding, and break to assess (communication):

Kate (developer): Problems that can be solved with software, pro/con for various options?
Darnell (biologist): ditto for molecular biology.
Xue (non-technical manager): Context. What are other teams doing?

After a few days of assessment, there is another meeting. Xue outlines the high-level overview discussed previously to make sure everyone is on the same-page about the problem. Kate (developer) presents the pros/cons of a few software options. Darnell (biologist) follows suit for molecular biology (communication). The group discusses the various options (mutual ownership); in consultation, Xue chooses the set of options to be implemented, and leaves the implementation details to Kate and Darnell. As the week progresses, software and biology changes are applied. Kate and Darnell touching base to reassess their understanding if an interface becomes unclear, or additional dependencies arise (gradient awareness). Their ‘local’ solutions each contribute to solving the ‘global’ problem. Concerns have been separated such that developers aren’t telling biologists how to do their jobs, and vice-versa.

Applying separation of concerns is an art

There are no right answers. The central challenge lies with each specialist coming to a common understanding of their interfaces with peers, walking the tight-rope of openness (about what) and abstraction (about how). Thus, applying separation of concerns simultaneously requires teams to understand more of the overall problem (what), so as to define sensible interfaces between team members, yet less of each-others implementation-level details (how).2.

If the proper balance of openness and abstraction is not achieved, then interfaces are either drawn too broadly (you’ll be stepping on each others toes and exposed to unnecessary implementation-level details), or too narrowly (the ‘local’ solutions of each team-member won’t work together to address the ‘global’ problem).

Done well, separation of concerns enables specialists to work together in harmony: delivering a reasonable set of ‘local’ solutions to the ‘global’ problem at hand.
Done poorly, separation of concerns stifles innovation by imposing artificial barriers: ‘local’ solutions which are ‘globally’ ineffective (and sad panda for all parties).

Cross-functional teams of the world, try giving the principle of separation of concerns a try on your next project.

---

1. As corollaries, “not my problem”, dismissal of your peers capabilities and inter-specialty rivalry are unacceptable. ↩
2. An added-benefit is that less field-specific jargon tends to be used because implementation-level details (how) are abstracted into higher-level problems (what). For example, everyone can understand that a software application is slow (what), but the biologist could (usually) care-less that it’s due to excessive network traffic (why), or that the developer resolved the problem by local caching (how). ↩

Ryan’s Guide to Job Search Strategy: Assets

#1) Assets: Skills, Credentials & Experience

Goal: To enumerate our assets, vis-à-vis our skills, credentials and experience.

Assets: The attributes and abilities you bring to the table to get a job done.

Learn: How to use shotgunning, expansion and clustering to build skills clusters of your assets.

You've seen the big picture, now it’s time for the hardtack of reducing our newfound mental model to practice. For convenience, we’re going to work in linear order, starting with Assets. Here’s a mental model, native loop model on the top, and the linearization on the bottom.

A visible expression of an asset is a concrete skill, such as computer programming. This skill can be supported by credentials, e.g. a University degree in computer science, or experience, e.g. a software development internship with Amazon. Great, you’ve loads of credentials and experience. Following your broken mental model, you’ll list your credentials and experience on a resume, highlight them in a cover letter and force fit them to job posting. And you’ll get nowhere.   

The problem with simply listing your credentials and experience, which is what we were taught to do under our broken mental model, is that no one cares. No one cares that you have a PhD from Harvard. No one cares that you've volunteered with an after-school program.

People care about what you can do for them, about your skills that are useful to them. They care about your credentials and experience, only in so far as they present credible evidence of your skills, and only in so far as those skills that are useful to them.

We need a way of taking our credentials and experience and decomposing them into skills, skills that people and companies may find of use.

Our new mental model has the answer in three simple steps: Shotgun, Expand and Cluster.

1.1) Shotgun

Start by enumerating any skill, credential or experience you can think of. You can use your resume as a starting point, or work through the exercise with a friend.

I've grouped skills, credentials and experiences separately, but there is no need for structure at this point. You want to think as expansively as possible. If structuring helps, great. If a scatter plot works, also great.

1.2) Expand

Great, I've 9x solid items, 3x for each of skills, experiences and credentials. Let’s pick a few of these items and expand. Think about related items and write them down. Here’s mine:

I've chosen to expand a related experience and skill: NaturalMotion, a game middleware and free-to-play game company I interned with last summer, and computer programming, a skill I used extensively as an R&D intern building prototypes for NaturalMotion.

1.3) Cluster

Now that we've generated many skills and experiences, it’s time to cluster and connect them.

Think about the words and ideas that connect your varied activities. For clarity, I've colored connecting ideas in red, skills in dark blue and experiences in light blue. Ideas and skills are connected with lines. Related skills are connected with dashed lines. 

Things to think about:

• What is related?
• Python is related to Django, it's a web development framework.
• Where have I employed a particular skill?
• I wrote an integration test suite in Python
• What experiences did I have while earning my credential?
• I've written and presented loads of technical material during the course of my PhD

All paths should eventually end in a skill; however, it’s just fine to end with experience and cluster the skills elsewhere. This helps keep your clusters organized, which will be useful in the next step, putting your skills in the context for Mr. Market!

Tool Tip

draw.io is a wonderful tool for quickly making simple figures. Built-in integration with Google Drive and Dropbox allows it to easily tie-in with your existing workflow.

Guide Navigation
Previous: A More Effective Mental Model

Next: Mr. Market

Ryan’s Guide to Job Search Strategy: A More Effective Mental Model

A More Effective Mental Model

Here it is, my mental model of an effective job search strategy.

The first thing you’ll notice is that it’s loop driven, not the linear mental models to which we’re most accustomed.

The mental model is composed of two loops, the inner and outer. They are mutually interdependent, but due to their different focuses my be optimized independently.

The numbers at the top of each sub-loop, e.g. #1 for Assets, represent a linearization of the inherently non-linear loop-based mental model. I choose this linearization for convenience, but you can start anywhere on a loop-based model.

Inner loop - Assets, Mr. Market, Aspirations

The inner loop is primarily concerned with you. Your assets, your aspirations, and their context with respect to Mr. Market. This is the mechanism by which you choose where to play.

Outer loop - Companies, People, Applications

The outer loop is primarily concerned with others. Who they are, what they want, and the hoops they force candidates jump through, particularly for larger firms. This is the mechanism by which you actively position yourself to win an interview, and eventually a job offer.


Guide Navigation
Previous: Your Mental Model is Broken

Next: Assets: Skills, Credentials & Experience

Ryan’s Guide to Job Search Strategy: Your Mental Model is Broken

Your Mental Model is Broken

Volumes have been written on strategy. In short, it comes down to choosing where to play and positioning how to win.

Unfortunately, the mental model of job search and acquisition that most of us were taught doesn't do either the where or how, let alone do them effectively.

If you’re like me, you were taught that if you gather enough qualifications/experience, work on your resume/cover letter enough and apply for enough positions, you would clear HR, land interviews and eventually a job offer.

The reality couldn't be further from the truth. For me, enough never happened. Enough doesn’t exist because my mental model was broken. My mental model, and I suspect yours as well, leads only to despair, not job offers.

I’m going to rework the first part of your mental model, the job search. If there is sufficient demand, I’ll cover interviewing and choosing between offers in a later guide. I've chosen to start with job search strategy because there downstream issues are a moot point if you don’t land interviews, or even better, so impress someone that you’re hired on the spot.

Guide Navigation
Previous: Introduction
Next: A More Effective Mental Model

Ryan’s Guide to Job Search Strategy: Introduction

Introduction

This is your strategic guide to the initial stages of your job search.

If you’re like me, most of the career advice you’ve read, or otherwise received from good intentioned friends and colleagues, is vague and unhelpful. Obviously, I cannot guarantee you a job, but I will present a roadmap, a crystallized instance of a job search in progress.  

Herein, you will discover the mental model and accompanying strategy that I have developed, and am actively using in my own job search. The first collection of articles will focus on the initial stages of search. We will start with a high-level mental model, and proceed by systematically covering the concrete steps that will help you turn that model into reality. Specific examples from my own job search are included at every step. So let us begin...

This Guide is for

• Recent graduate who have no idea how to apply their degree in practice.
• PhDs who long to leave academia, but don’t know how (this is me, by the way)
• People who (naïvely) followed their heart at age 18 with no thought to the future.
• Long-term unemployed.

Guide Navigation
Previous: N/A
Next: Your Mental Model is Broken