“The value of a company is the sum of all problems solved.”
The last season of Startup, Gimlet's first podcast, discusses their acquisition by Spotify, and it has some interesting behind-the-scenes stuff (maybe not as much as I'd like, but ...)
One of the ongoing themes is the tension between Alex and Matt, the co-founders of Gimlet. Alex cares more about the quality of the product and Matt cares more about the business needs, and Gimlet was struggling, even in the quarter preceding the acquisition. Neither of them were handling the conflict very well.
In this episode, Thanksgiving in Stockholm, Alex is talking with Daniel Ek, CEO of Spotify, after the acquisition has happened to reflect on prior conversations they'd had before.
[36:28] Daniel Ek, Spotify co-founder: It's actually my co-founder's [Martin Lorentzon] saying. He said this thing, I'm not even sure he was aware that he coined what I think is an iconic quote. He said, “the value of a company is the sum of all problems solved.” Even to this day, it's one of those things that I think about. You may think about all the things you guys went through as all the issues that you went through, but you solved them, one by one. And I think the most important thing that you got right is the integrity of the programming and the shows that you make. At the end of the day, that is the value that you're bringing to that and bringing to consumers and it really served you well in the end.
Then Alex sums up his thoughts in a way I don't quite agree with.
[37:20] Alex Blumberg: In other words, Matt's and mine constant fighting had produced something valuable, the fighting itself in fact was the thing that made it better. If I hadn't cared about what I cared about and he hadn't cared about what he cared about and we hadn't each cared enough to fight with each other, the company we built, it wouldn't have worked as well.
It's the caring that matters, not the fighting. It's possible to combine caring with good conflict resolution skills and minimize the fighting. Then things are even better.
In his book, Slack, Tom DeMarco writes:
Slack is a prescription for building a capacity to change into the modern enterprise. It looks into the heart of the efficiency-flexibility quandary: The more efficient you get, the harder it is to change. The book shows managers how to make their organizations slightly less efficient but enormously more effective. It coaches them on the introduction of slack, the missing ingredient required for all change. It counsels a thoughtful use of slack instead of the mindless obsession with elimination of all slack in the interests of efficiency.
The other day on the job one of the devs on my team posted a PR for code review with a comment like: “This removes X from the codebase. It's not terribly important, but it's been bugging for a long time and I'm glad to be rid of it.”
I realized that the presence of such PRs is an interesting metric to measure the amount of Slack of my team.
If they're too efficient in knocking out cards from stakeholders, I probably won't see any work like this.
Willem van Bergen, in the devproductivity.io Slack, mentioned a talk given at the @Scale conference of September 2017 that shared an internal study done by Google around the productivity costs of their build speeds. Taking aggregate data from tracks of how individual engineers are spending their time, they arrived at this graph:
The speaker Collin Winter had this to say about it (starting 27:44 into the video).
This is a graph from a report that we just published internally a few weeks ago that looks at, for builds of a different duration, how much time are people spending in each of these different cognitive modes. What we can see here is slow builds, builds lasting more than an hour, actually aren't taking that much time in aggregate. Likewise, builds that are really fast, well, they’re really fast, and they’re also not taking that much time in aggregate.
But we can see here that builds in the 2 to 5 minute range and the 5 to 10 minute range, those are actually pretty expensive. … That red bar is time where, as far as we can tell, people were just sitting there twiddling their thumbs staring at the terminal. … We can see time where we simply don’t know what they were doing [yellow].
It looks like the 2 to 10 minutes range is where we should spend our optimization effort and we can use that to focus our efforts more intelligently than a scattershot approach.
I'm of two minds here. Part of me is really interested in this data, but I'm also doubtful. They must be making some possibly large presumptions when interpreting the data of what counts as “untracked” vs. what's “waiting”. I'm also curious if this data is collected from their entire engineer population, or just volunteers? Do they know they're being tracked? How do they deal with the Heisenberg effect?
If the data is trustworthy, and I have a 15 minute build, will I make things worse by getting it into the 2-10 minute range? And how large does my engineering team need to be before any of this matters?
Read at medium.com
I've had the privilege of working remote for almost 5 years here at LivingSocial. Remote work still gets big time plugs, but it seems many places, including young, hip startups don't buy it, that co-location is an important attribute for a team.
And I get it. Co-location was a big deal in the Agile movement to help foster communication. But having worked remotely for 5, managing 3 teams of almost 100% remote employees, why don't I care?
I think the co-location agile pushes has much more to do with communication than proximity. Proximity can greatly drive down communication costs, but these days with Slack and Google Hangouts (to name but a couple), communication can be had without proximity.
Want to build a great team? Google studied this for a long time, and on a recent Freakonomics podcast (How to Be More Productive), Stephen Dubner interviewed Laszlo Bock, SVP of People Operations at Google about their Project Aristotle.
After analyzing data from 200 teams across Google of all varieties, they derived five “norms” the best teams at Google had. Things that weren't on the list?
... in the academic research it says consensus-driven decision-making is often better than top-down direction. And academic research says workload matters a lot. Having teams in the same location. We actually found none of those things were in the top five of what mattered in terms of effectiveness for teams. (around the 24 minute mark)
What did top the list?
the most important attribute of a high-performing team is not who leads it or who’s on it or how many people or where it is. It's psychological safety.
Charles Duhigg, author of The Power of Habit elaborates:
Which means that everyone at the table feels like they have the opportunity to speak up, and they all feel like each other is actually listening to them, as demonstrated by the fact that their teammates are sensitive to nonverbal cues.
We ask if the team members feel that they can fail openly or do they feel that they are going to be shunned by failing? We ask, do they feel as if other team members are supporting or undermining them?
Or, as I would say it, they're on a team that doesn't shame them. See BeyondImpostorSyndrome for more.
The four other norms Bock identifies are Dependability, Structure and Clarity, Meaning, and Impact. He also tacks on the importance of actually doing 1:1s, and making sure everyone feels included, don't let the dominators dominate.
Which I love.
But I love umpteen times more the first point.
Low shame teams beat out other factors. So does low shame anything.
If you're outsourcing your soft skills to the fringe of your organization (or congregation, or marriage, or friendship ...), you're prolly not doing it right. You're probably also bored and/or frustrated out of your mind.
Read at medium.com
From my little corner of the internet, Impostor Syndrome seems to be getting more attention these days, which is cool. But there’s a bigger world underlying it. Camp out in the mines of Impostor Syndrome and you may miss out on what lies beneath and the resources we have to combat it.
“It” … is shame.
Shame is about my identity. We typically talk of shame in false views of self (“I should be better than I am/I’m unlovable”), though an accurate view of self I’d label as “healthy shame” or humility (“We all make mistakes/I need help”).
Impostor Syndrome is rooted in shame. It speaks to specific instances of identity struggle, usually involving a sense of deception or fraud about our work and accomplishments.
But the shame underneath in each of us can play out in many other ways.
The refusal to pour out my heart’s frustration over making a grocery list with my significant other because it’s just an f’ing grocery list and I don’t want to feel like I’m being disrespected over something so insignificant.
The apology I interrupt myself with to make sure no one has an adverse reaction to my opinions.
The verbal shove to make my friend think twice about asking me that question again.
The give-up on taking care of myself because there’s nothing worth saving here anymore.
The king-of-the-hill race to drop knowledge so that no possible conflict can occur because I allowed someone else to muddy the playing field with something confusing or imprecise.
The faux-patient submission to an unyielding relationship I tuck deep down in my purse of resentments.
The refusal to speak up to an act I’ve been guilty of myself because who am I to out myself as a hypocrite.
The spoken snub to try and silence the proof that I’m not really comfortable with how others express themselves.
The interruption of my spouse’s story to make sure they get it right so others won’t think poorly of me because of my ignorant other.
The justification where I draw the line so help me god you can have everything else, but not this.
The turned over phone, the ignored text, the deleted email.
Years ago I knew of a man in his fifties or sixties, a successful business man, who had a secret: he couldn’t read. He’d worked around it his whole career, had figured out how to have others read for him so he would never have to.
As part of his recovery he decided to remedy this. The tutor started with some simple reading samples to get their bearings and by the time they were done, it was determined he could actually read at about a 7th grade level.
His shame around reading had skewed his beliefs so much over the years, that he really didn’t think he could read at all.
The topic of depression is pertinent as well here. While I believe everyone copes with shame, those who receive their helping of shame swimming in a gravy of depression have it rougher.
The physiological effects of depression are akin to circus mirror glasses on top of the blinders of shame. I’m a bit (more) out of my depth to talk about depression, other than to say my spouse and I have struggled through hers our entire marriage. Successfully, I might add, on the whole. But it’s no small beast.
How, then, do we cope?
For many, anger is the defender of our secret shame. Look behind it, what’s it so desperate to guard?
For others, withdrawal and fear are aiming to protect. Peel it back, what’s beneath it?
Look for hurt. For loneliness. And look for false beliefs. Toxic shame arises from lies. Tie yourself to something right.
Stay connected. Shame removes options, isolates. Do not hesitate in getting help from someone trained in dealing with it. And when you hesitate and the shame wins for a day, get some help again.
Shame runs deep. But we can learn to recognize it, in all its myriad ways. If Impostor Syndrome has been your introduction, keep digging.
Brené Brown has some wonderful resources on shame, see her site here: http://brenebrown.com. These TED talks of hers are good introductions: Listening to Shame and The Power of Vulnerability.
Greg Bauges has a great blog on the topic of Depression with a focus on the Software Developer community, and runs a support site at http://devpressed.com/
A couple of recent tweet conversations prompted me to get this out of my head and into words. Thx to Glenn Vanderburg, @gregvaughn, kerri miller and others for, at the very least, allowing me to invade on their tweet-turf. Thanks also to folks who additionally reviewed this article for me: Tara, Adam Keys, Morgan Whaley, @erniemiller, and Tony Pitale.
I gave a little lightning talk on TechnicalIntimidation at RailsConf 2013 which touches on these topics, video and lots o’ other links there. If yer a techie, give it a spin.
Ran across this
article from Twitter's Engineering Effectiveness group thinking
about how big a team needs to be before dedicating a portion of that
team to aiding the rest of the team pays for itself.
Not necessarily hard answers, but thought provoking content.
My current LivingSocial cohort Shane Warden shared an article the other day titled “The steel man of #GamerGate”, which isn't really about #GamerGate but about steelmanning, “the art of addressing the best form of the other person’s argument, even if it’s not the one they presented.”
Which was timely, because the most recent This American Life features a bit where producer Alex Blumberg got to pitch a startup idea to Chris Sacca, and Sacca expertly steelmanned Alex:
At a certain point, Chris drops the pretense that this is an actual investor meeting and just starts coaching me on my pitch, feeding me questions, and then correcting my answers.
“Give me a second and I'm gonna give you your pitch back.”
And then, right there, not far from the freeway overpass near Pico and Bundy, he steps into the role of me, starts giving the pitch I should be giving.
Alex Blumberg: That was amazing!
Chris Sacca: That's your story, right?
Alex Blumberg: That is great. Holy [BLEEP]. I thought I was a storyteller. Now I feel bad about my job.
I'm thinking, oh, if he pitched my idea that well, he must be into it, right? He's going to invest. But then he goes on.
At this point, I have no idea what to think. I'm drained, my pits are drenched, and Chris Sacca has just given me two completely convincing cases in favor of and against investing in my business. Whatever shred of conviction I had about this process at the beginning is gone.
Audio for this portion starts around the 24 minute mark, though this story is the first in the episode, so you can also just listen from the beginning.
This also overlaps with the conflict resolution skills my wife and I were taught and what we also use when working with other couples, to endeavor to repeat back to another person what was heard, to make sure a problem is mutually understood before attempting to rectify anything.
A friend of mine recently asked for advice on pitching himself to a group of developers for a project management spot at his gig. He was feeling the weightiness of asking to help manage a group of people who do work he doesn't deeply understand himself.
Rather than try to pitch them on projects he had successfully managed before, we talked about what I want, and I came up with this pitch:
- you'll work to keep them from getting blindsided, which has some sub-points:
- pushing on them to get as much understanding as to what needs to be done to communicate it to the customer (it can be a strength that you don't know too much about what they do. once you understand it, the customer can too).
- not pushing into the unknown and forcing answers where they don't exist yet (e.g. no numbers in estimates, identifying amount of perceived risk in addition to perceived effort).
- working out contingencies with them.
- you'll defend their work environment to enable them to do their best work, tailored individually as much as possible.
- you'll run interference for them transparently and tailored individually. I personally favor as little interference as possible. Others may want more. Running interference means reducing noise to increase signal, it doesn't mean making yourself a required part of every conversation. Every involvement you have costs something, so make the costs pay for themselves. Make your ideal this: that you're ultimately not involved at all, that the customers go directly to the people building the solutions at all times. Then work backwards from that. When you notice you're superfluous, get out of the way.
What would you say?
Rails 4 has moved its
rails command to the
bin directory of the application, but this collides with any existing
rails command put there by the
--binstubs flag, and the two are not compatible.
The recommended way to use binstubs with Bundler and Rails 4 is to not use the global
--binstubs flag, but to call
bundle binstubs [gemname] individually on gems you want in your local bin folder. For some background on these changes, check out these commit comment threads: rails bundler.
There was an attempt to make Bundler 1.3.x not override anything in the bin directory if
--binstubs was in effect, but that change was reverted for semantic versioning. My understanding is this change will be re-attempted in Bundler 2.x.