Author: cdwan

2017 Lab Informatics Summit

I had the opportunity to speak at the lab informatics summit on the topic of cloud technologies. It was a lot of fun, I caught up with old friends, and made a few new ones.

Also, I got to explore Philadelphia. I came away really liking the city.

Here are my slides:

Consultants vs. Contractors

A few weeks ago I wrote about the distinction between bioinformatics and computational biology. My point in that post was not to be absolutely correct about the definitions. Rather, I hoped to encourage conversation around the differences. I hoped to light up the importance of considering this distinction when planning and executing on projects.

There is a similarly valuable distinction to be made between contractors and consultants.

The core of it (for me) is that contractors are paid to do the project itself, where consultants are paid for their opinion, advice, and support – usually framed in highly actionable recommendations.

Opinions will, of course, vary. Please leave comments, particularly if you disagree!

With that framing, you can see why it’s important to know which kind of engagement you’re signing up for, either as customer or provider. I’ve had projects go rather radically off the rails because of mixed signals on the role that I was expected to play.

Note that many of us walk in both worlds. Most people spend the early part of their career doing projects, and transition to opining and advising once they have the benefit of that experience. There are, of course, exceptions, particularly when the services are closer to coaching than engineering.

This also ties into the question of how to set rates.

Finding the appropriate value for a contracting engagement tends to be relatively straightforward. The customer usually has an idea of the value of having the project complete, and has an idea of what it would cost them in staff effort and wall clock time to do it in-house. If that value (to the customer) is greater the amount that the contractor needs in order to make it worth their while, then there is space for negotiation.

Consulting roles are harder to quantify, though it is possible. One fruitful approach is to look at the expected costs / returns of various project outcomes. One need only look at the costs of a ransomware attack, data loss, or HIPAA violation to see that there is plenty of space in the information security field, both for good advice and also for robust operational practices.

As usual, I’m excited to hear your thoughts on this – doubly so if you think I’ve missed something important!

Setting rates

This is a post about money – specifically about how to set consulting rates. It builds on two prior posts about the legal mechanics and some business development practices of my one person consulting shop.

People tend not to talk about the specifics of compensation. Because of this, most of the advice that I’ve read over the years has been vague to the point of uselessness. There are various reasons for that – mostly centering on cultural squeamishness about money. My opinion is that while discretion and humility around the absolute numbers are good things, we need to be able to talk about this sort of thing far more openly than we usually do.

The majority of this post is about figuring out what you need – a minimal baseline that will cover expenses. At the end, I offer a bit of a vague tease about figuring out what the market will bear. It amounts to “until you have data based on your own experience, you have to ask your friends.” This will take emotional energy and trust – especially at first – but it’s absolutely essential to go into negotiations knowing both common practice and your baseline requirements.

As usual, this is based on my experiences and those of a few trusted friends. Your milage will almost certainly vary. I’m curious to hear your comments.

The Salary Comparison

A consulting rate is very different from a salary. In fact, comparison with a salary is among the worst ways to figure out an appropriate rate to charge for your time:

Consider the old shorthand:

There are approximately 50 weeks in the year, and 40 hours in a work week. That means that there are 2,000 hours in a work year. If your aspirational annual salary is $100,000 (a round number makes the math easier) you can just divide by 2,000 to get an hourly rate of $50.

The problem with this approach is that it’s misleading and causes you to under-charge.

It is unwise to bet on being 100% billable, particularly over the long term: I’ve been consulting for a while, I’ve got a strong professional network, and I treat business development as a core component of my job. My experience is that I can sustain between 70% and 80% billable time (against the arbitrary 40 hour week). A safer assumption until you have data on your own network and capacity is 50%.

Vacation: Even if you personally decide that you don’t need to take breaks – many customers will go completely dark on you during national holidays and also from mid November through early January. It’s also challenging to get the right people in the room during the summer.

There is a lot of non-billable work in consulting: I’ve written before about “business development Fridays.” If you want to have billable work, you must do non-billable work. This inevitably cuts into your ability to meet that notional 40 hour, 50 week schedule.

There are a lot of non-salary expenses that an employer would usually cover: Health insurance is the big one, and the self employment tax works out to about 7.65% right off the top. Also consider any sort of employer contribution to a retirement fund, transportation benefit, funding for education or conferences, and so on.

Business expenses: Distinct from the non-salary benefits, you also incur direct expenses. Even the small ones add up: Computers, printers, shipping, an attorney to review contracts, an accountant to prepare taxes, liability and other insurance, a co-working space to host meetings … these things all need to be funded out of the consulting rate.

Multiple budgets

A better approach is to start with a budget, or rather at least two budgets. Even though I’m a one-person shop and the IRS doesn’t really care whether I keep dollars in this checking account or that one – I still make a strong distinction between my personal and my business finances.

Start with a personal budget. Keep it high level, and be sure you get all the major expenses in there. Housing, health insurance, utilities, transportation, childcare, saving, etc. In order to keep from getting distracted by the details, I set an arbitrary requirement that it had to fit on one sheet of paper.

Note that taxes are not in the personal budget – I’ll get to that in a second.

The bottom line on the personal budget was the number that I decided to transfer from my business account to my personal account every month. That’s what I decided to pay myself.

With that in hand, I had the first line for my business budget.

This second budget is similarly high level. It includes liability insurance, all the expenses listed above, and also a line for taxes based on an assumption that a little less than 50% of every dollar I receive will somehow go out the door to the city, state, and nation.

The bottom line of the business budget is the actual amount of money that I need to bring in every month in order to make this independent consulting thing work.

That’s my number.

The tyranny of the number

When I started out with BioTeam in 2004, Stan insisted that each of us work to a ‘number,’ an amount of revenue attributable to our work. At the time I resisted it – how could a number capture the grace and beauty of my engineering contributions to the team? How base and unseemly for a software person to be tied to a (yuck!) sales goal.

Technical people, I am speaking to you, are you listening? Get over that squeamishness and learn to love your number. It is how you get paid.

Now the only thing left to do is to figure out how to turn that number into a rate.

Setting a rate

Having done the work above, you know the total amount of dollars that you need to bring in (on average) every month. The next question is how to chop that up into hours, days, and deliverables to make it work.

I made a little chart breaking out my required rate under various assumptions. This gave me a baseline – the minimum that I could possibly charge, under various conditions. Because of the bottom-up approach, I also had a good feel for what I might need to charge for fixed fee deliverables like blog posts and technical assessments.

Then I went out and did some market research.

What the market will bear

Of course, you shouldn’t simply charge the minimum. Instead, you should charge an appropriate and fair rate for your services. There are several ways to define “fair” in this context. All of them involve talking to people about money.

The very best thing to do is to ask peers who either provide or consume consulting services about what rates seem reasonable and common to them. This is best done one-on-one with people you trust. Over time, you will get more comfortable both asking and offering this level of detail.

Negotiation is a whole different topic for a different blog post, so I’ll just summarize here:

Figuring out if an exchange is “fair” requires that both parties understand the relative values involved. If you’re going to be an effective partner in negotiations, you must understand your requirements before walking in the door. The whole top portion of this post was required just to be able to hold up your end of the business conversation.

If you don’t have information both on your needs and on the common practice in your industry, the other person might suggest that you take a reasonable salary number and divide by 2,000. Seems “fair,” right?

Go Around

When I was working with the NY Genome Center from late 2011 through early 2014, I took the opportunity to drop in and train at Oishi Judo Club in southern Manhattan. It’s a great school filled with strong, friendly, skilled judoka of all ages and backgrounds. It was the perfect place to balance out the stresses of living in hotels and working at the edge of my capacity.

One of the people at Oishi, Paul Virtue, taught me a great life lesson that I apply frequently in my professional life.

The summary / mnemonic is: “Go around.”

Paul is vastly stronger and more experienced than me at Judo. He’s a lifelong athlete who competes internationally in several martial arts. He’s also a careful training partner – I was never worried that he would injure me. I always considered it an honor that he would train with me. One of the things that I love about the Judo community is that it is filled with people who are so generous and careful as they share their expertise and experience.

Anyway, Paul and I were grappling one day, and I found myself frustrated that I couldn’t get past his “guard.” I was pushing hard, tiring myself out, but to no avail. He was just too strong. Our different levels of physical conditioning meant that he was going to remain stronger than me as we both tired out. After a few minutes of this, he looked me in the eye and said:

“That’s never gonna work! Go around, man, go around.”

Note, he didn’t say “give up,” “you’re not strong enough,” or anything like that. He also didn’t make a point of flipping the situation around with a cruel, “time’s up, n00b.” Instead, he gave me exactly the tip that I needed at that moment – rather than either shutting me down entirely or encouraging me to continue on a hopeless path – he gave me permission to try a new approach – to be curious and experiment.

What does it mean to “go around?” It’s just that since I couldn’t move him from where I was – I had to move myself. with a new perspective, it was a different problem.

Note that this wasn’t a miracle cure. There was no rapid training montage where I was suddenly just as strong and as skilled as him. Instead, we rapidly evolved to a new stalemate – but then there was another and another. In that series of transitions I discovered a joyful new level of judo practice. It was no longer a test of strength on strength – being strong enough to beat the other person – but rather one of agility and flexible perspectives.

People say that training with the founder of Judo, Jigoro Kano, was like “fighting an empty jacket.” By the time you would bring force to bear, he would have already moved out of the way.

The best engineers I’ve worked with have had this same supple tenacity, turning problems over and around until they suddenly become simple enough to solve.

Recognizing when a particular approach is never going to work and adapting around it isn’t failure (though it frequently feels like failure at the time). Instead, this is the higher level of practice – whether you’re grappling with a gnarly technical problem or an experienced athlete.

It’s a lesson that I took back to my work at the genome center – the team worked around strange configurations of fiber in the street, remarkably complex construction delays, evolving funding sources and strategic imperatives, and even a hurricane that flooded southern Manhattan. In every case, “going around” turns out to have been much more effective and powerful than merely powering through.

If you can’t budge the problem from where you are – then you have to move yourself.

Go around.

Be Humble

Full disclosure, I’m really quite interested in unconscious bias, understanding the impacts of diversity, and also on being as impactful as I possibly can. I would like to be aware of the context, and to do a good job within it. I have opinions on these matters.

With that said: I recently read an article in the Harvard Business Review about Why Diverse Teams are Smarter. In that article, the authors link to a remarkable study. In that study, teams of people are asked to solve a puzzle. Those teams start out with three people who are all from the same fraternity or sorority. They are joined midway through the puzzle by an additional person. That person is either a member of exactly the same greek organization (“in group”) or a gender matched member of a different organization (“out group”).

Note that we’re not talking about something truly uncomfortable and fraught – like ethnicity, gender, sexuality, religion, nationality, or … well … the whole laundry list. We’re talking about testing whether being in the same fraternity vs. the neighboring house full of gender matched privileged people makes a difference in performance on a made up test in a controlled environment.

From the abstract: Groups with out-group newcomers (i.e., diverse groups) reported less confidence in their performance and perceived their interactions as less effective, yet they performed better than groups with in-group newcomers (i.e., homogeneous groups). Moreover, performance gains were not due to newcomers bringing new ideas to the group discussion.

Less confidence in their performance, perceived themselves as less effective, performed better, no new ideas.

Rest with that for a moment.

Felt worse, did better.

So then I thought about my role as a consultant. I’m the out group. I drop in and try to help the team solve the same puzzle they’ve had for years. Realistically, in most cases, I bring very little truly new information.

Sometimes people say that I had a major impact. That I transformed things. That it’s cool to be able to rent a unicorn.

They say that it was uncomfortable – uncertain, but totally worth it in the end.

I rest with that.

I think that Kendric Lamar said it best:

Be Humble

Shifting genomic data to the cloud

I had the opportunity to write a white paper for Elastifile about the challenges and opportunities as we shift large quantities of genomic data from traditional on-premise NAS systems to the cloud.

If that’s the sort of thing that interests you, check it out here: Escaping Data Gravity.

If you have feedback – positive, negative, or indifferent – I would love to hear it!

Putting data beyond ownership

Some blockchain implementations – public, non-permissioned ones in particular – have a really interesting property:

Nobody owns them.

As a sentence, it’s a simple statement. There is no owner.

As I’ve considered it, however, this is far more subtle and powerful than merely having a NULL value in the field where we usually write down the owner’s name. It is not merely that these systems do not have an owner right now, nor that there -is- an owner who has given broad permissions around the use and re-sharing of the data.

Rather, these systems are by design non-ownable. It might be accurate to describe them as “self sovereign,” though in a limited sort of way.

The foundational example of a blockchain system, BitCoin, was designed to solve an accounting problem in a low trust environment: The designers wanted to keep a ledger of transactions among a group of parties who did not trust each other to keep the books. They also didn’t trust any particular third party, whether it was a bank or a nation state.

The solution to that problem was to create an escrow service. In effect, the BitCoin network created the third party that they needed. That third party was sufficiently disinterested and transparent that the participants were comfortable using it to keep the books.

People are making increasingly clever use of this property of BitCoin and other public chains. It serves as a highly trustworthy and disinterested repository of data. It is useful precisely because there is no chance of a conflict of interest or an external force changing the system. While we do worry about it failing and becoming unviable, we do not worry about the owner being bought by a competitor or compelled by a nation state.

There is no owner to compel. I keep coming back to how -odd- that is.

Note that this is distinct from the question of whether the data itself is public, private, or bound by one license another. Uploading copyrighted material to a blockchain service does not invalidate the copyright. The copyright is still valid. Instead, it means that the party that received the data isn’t a person or a company.

This new model opens up possibilities for system designers and data strategists. Many of the challenges in our health care system center on the obligations, risks, and potential rewards of being the organization who owns the systems that hold the data.

Under current law, the data in a person’s medical records belongs to that person. However, the electronic medical record systems that hospitals use to record the data belong to the hospital. Hospitals exist in a web of frequently conflicting pressures, risks, and incentives. Anybody who has navigated the American health care system knows the awful challenges involved in accessing and sharing data that we supposedly “own.”

To be clear, using the BitCoin network to directly store electronic medical records is a terrible, half-baked, hopelessly naive idea. BitCoin is built on the wrong set of incentives for health care. It operates at the wrong tempo. It also has structural and social baggage that make it a bad choice for this particular application.

More fundamentally, data that should remain private over the long term should not go on public chains, even encrypted. Encryption has a shelf life. The computers of the future will be powerful enough to break the encryptions of today.

With that said, I do think that there is a great opportunity to change the rules of the game by considering which slices of information hospitals and insurance companies and research organizations hold closely because they can’t trust each other. Then we should ask: “What if we let ‘nobody’ hold some of that information, instead of any of us?”

Nobody cares about the cloud

Nobody cares about the cloud.

It’s a statement that requires a bit of explanation – since “the cloud” is so ubiquitous. I see it advertised on highway billboards, in airport concourses, and everywhere in between. I believe that my current resume and LinkedIn profile may even mention “cloud transformation.”

All of us connected to information technology have been immersed in a decade long frenzy of cloud. Personally, I’ve built production services using at least five different public clouds. I’ve built private clouds using both OpenStack and VMWare. I’ve smeared a single service across multiple public and private clouds (hybrid cloud), used a public cloud to provide additional capacity beyond my on-premise infrastructure (cloud bursting), and hosted one service on one public cloud and a different service on a different cloud –
all for the same enterprise (multi cloud).

I’ve made fun of more than one vendor who tried to convince me that their same old capital intensive, on premise offering was competitive and modern because they had switched to monthly billing with bundled support (enterprise cloud).

I’ve glared balefully at people who tittered about calling a legacy on-premise infrastructure a “fog.”

It’s a cloud that’s close to the ground. Get it?

And yet I claim that nobody cares about the cloud. I suppose that, to be completely honest, I actually mean that I don’t care about the cloud.

I mean this in the same way that I might say that I don’t care any particular Linux distribution, any particular CPU or GPU, or the very latest iPhone.

I’m a technologist, I use technology – but not for its own sake.

I care about what these technologies can let us do.

I care very much about accelerating the tempo of biomedical research and drug discovery. I have been in this industry for nearly two decades now, and it is going too damn slowly.

I care about democratizing the benefits of genomic medicine. Access to these cures is still far too dependent on being rich and having the right connections. Technology can help to reduce that unfairness.

I care about helping my clients to be more competitive as they search for leads, compounds, patents, products, and cures.

I care about ensuring that caregivers, from family through to physicians, have accurate and timely information – and that they can share that information with each other to give the very best care.

I care about appropriate usage of information. I care about preserving privacy while still enabling data driven therapies and intelligent interventions.

I care about empowering people, with both technology and education, to make informed choices.

I care about, in the words of Paul Farmer, “preventing stupid deaths.”

The cloud is a means to an end. It’s a fuzzy and overhyped term for a remarkable and transformative set of technologies. It’s right at the very core of my industry, and I really truly do not “care” about it at all.

I care about the mission.

I don’t care about the cloud.

Bioinformatics vs Computational Biology

In the past, I used the terms “bioinformatics” and “computational biology” somewhat interchangeably. I don’t do that anymore.

  • Bioinformatics is about reusable tools and information resources for biology.
  • Computational Biology is about biological insight.

It’s not necessarily a distinction between two different types of person. I know plenty of people who can do either type of work, building tools and then using them in their science. That said, people do seem to sort themselves to focus either on tool building or else on hypothesis testing.

The distinction is important because the metrics of project success are different, because we should manage projects and teams differently based on those metrics, and because career advancement and mentoring diverges rapidly between the two.

As always, I’m interested in your feedback, particularly if you disagree with me!

Less Rage

I find myself wondering, this morning, how we can begin to reduce the amount of anger in the world. The snap responses and rage seem to appear and re-escalate every attempt to defuse and begin to heal our cultural divides.

And I realize as I write these words, that the only possible answer is to start with myself. Where else can I get a toe-hold?

I learned in Judo and Jiu Jitsu – in my body, because my mind wasn’t ready for it – to stop waiting for the other person to do some thing that I wanted, and instead to always consider “how can I adjust -myself- to improve the situation?”

So I’m doing that now.

I’m going to try to be as kind as I can today – to everybody – whether or not they “deserve” it, without checking to see if we agree on the issues of the day, and without expecting anything in return. I’m going to try to turn down my own rage, and to turn down my tendency to trigger other people into rage.

This doesn’t mean yielding on my beliefs or assenting to horrible things. I will continue to speak up for the change I think we need to see in society.

I’m just going to try to be kind as I do it, and if I can – to elicit kindness in return. To everybody. No exceptions.

I know that many of the people who read these words already do this, every day. For that, thank you. You are helping. You are an inspiration.

I know that many of the people who read these words are in a place where nothing other than rage is possible, even for a short time. I know how that is. I’ve had a ferocious temper … really strong emotional responses … my whole life. Rage is strength. Rage lets you endure the un-endurable.

I know that I will not be perfect at this. I’ve made this decision countless times before. I will try and fail and try again and hopefully improve over time.

My reward, I hope, will be to live in a world with slightly less rage and anger. That’s what I want. I want that for you too.

I’m sharing because, I think that there may be some people who may read these words who might be in a similar place to me. As I’ve gotten older, I’ve realized the truth of what I was taught year over year by mentors and teachers … that people are actually much more similar than we are different.

So if you’re reading this, and if you’re in a place where you can choose to be kind, without giving up your strength and commitment to justice, equity, and all the rest, then I want to invite you:Let’s be kind together.