Don’t Silo Your Geeks

First posted on the Harvard Data Smart Cities here

I’ve just told another partner organization “Don’t silo your geeks!”  It’s about the tenth time this year that I’ve conveyed this message.

The way most organizations utilize research, mapping and data is the same whether the analysis comes from an internal group or a contracted partner. You ask the data folks to do some analysis, with a well formed plan to give them, then get the results and go do the thinking work to implement a new plan or improve an existing effort. So what’s wrong with this model? Everything. This model not only serves to perpetuate a gross misunderstanding, it also serves to devalue your own staff and to rob your organization of valuable insights.

When you take your broken car to a mechanic for repairs you tell them the symptoms and then leave them to do their thing. All good.  Unfortunately with data analysis you’re not just following a formula model like: issue+data+geek=result.  By handing over a specification or formed plan for analysts to follow, you’re missing the fact that the analysts know an enormous amount about what is possible, best practices for indicators, methods and communication styles, and about how to frame a research project to ensure your goals are met. Data geeks actually happen to know a lot about your work, your issues, and how to effectively think through a problem.  We’ve long treated data folks as simple number crunchers who know magic tricks that we leave alone to do their thing. That’s a serious misunderstanding.

Involve your data partners in your thinking, strategy, and planning and you ensure a higher chance of success for your project.

This approach sends a message to your data team or consultant that you really only consider them useful for doing the geekery, that they cannot possibly understand your problem or the end application of the data.  When organizations maintain the stigma of data analysts being simply geeks who like tech, you ensure those very talented individuals will never truly reach their potential in your organization.  Given the average analyst possesses traits including problem solving abilities, critical thinking skills and rare creativity, do you really think we’re using them best by siloing them away and perpetuating the geek stereotype?

More importantly, you ensure that your analysis is never as good as it should be by isolating the data folks from your initial thinking process, from your planning and brainstorming phase and your research formation efforts.

Would you take your car to the mechanic with a detailed procedure to follow? Not likely, you’d consult with them and develop a plan that includes their detailed knowledge and your broader mission (namely keeping your car reliable). Then they execute, you receive the results.  By engaging with your data folks in the early phases of a project you add valuable perceptions and insights, you allow for perspectives on what can be done, what would be problematic and how best to frame the plan.  You gain from having the folks who will execute your plan helping to form it, ensuring that your ask is reasonable and that your ideas can be executed upon.  A weak plan is nearly impossible for some research group to turn into a useful end product.  Involve your data partners in your thinking, strategy, and planning and you ensure a higher chance of success for your project.

Likewise, when you get your research report, data outputs, maps or other results, don’t consider the role of your data geeks to be over.  I’ve witnessed so many planning and implementation meetings where the folks in charge butcher the data analysis or misinterpret the maps, leading the effort down a bad path with less chance of the desired impacts.  Take the data geeks out of this stage and your chances of making similar mistakes are seriously amplified.  Keep your data partner engaged in this crucial last stage. Allow them to help form the end result, expect that you will raise up further data questions that will require more work to go back and answer.

A final benefit in keeping your data team involved at all stages is that you’re building the capacity and skills of your data folks, giving them insights to better guide their phase of the work, strengthening your team, and allowing for more diverse, experienced voices in your efforts. That’s rarely a bad thing.

Lost Opportunities?

The news today that a San Francisco Fire Captain was wearing a helmet mounted video camera during the Asiana crash rescue was quite something. Tragic details about the unnecessary death of the young traveler were caught on his camera providing priceless, objective information for the investigations and for reviewing procedures. This kind of information is not easy to digest nor is it something to be dismissed, yet that seems to have been the bureaucratically protective and regressive stance taken by the SF Fire Chief.

The Chief declared all cameras prohibited for fire dept staff. Blanket. Reinforcing a 2009 rule, this puts a clear message in writing for all to see. No cameras on duty. In any Fire Dept facilities.

There are numerous problems with this, some well detailed in the article.

Firstly this is a poorly timed public statement- when said video evidence is seeming indicting your own department for a horrible accident, now is not the time to ban all such devices- unless you straight up want to look  protectionist and in over-up mode. Who really wants that?

Secondly, it shows a poor leadership approach. Given that multiple fireys seem to be wearing the devices and the Captain in question stated these are extremely valuable training and learning tools, it sends the wrong message that common innovative practice is frowned upon and not welcome. Bad move.  Instead or rewarding creativity and progress, the Chief is slamming it.

Lastly, and this may be a behind the scenes reality, the Chief is losing the opportunity to learn from a delicate and tough situation – failing to adapt the new knowledge available and use it in the smartest way possible.  The message to the department and the public should have been that the use of cameras has been forbidden in the past, but this incident brings up a valuable perspective and the chance to review this policy and to develop solid guidelines for the safe, privacy protecting use of cameras in future.

HIPPA isn’t some bogeyman that disallows all information collection, it’s a set of guidelines as to what you can and cannot do. The use of helmet and other mounted cameras seems like an incredible value to our fire and rescue forces.   Good leadership takes a innovative approach to legal limitations and finds ways to support the good thinking of staff. 

Simply reiterating the public message that cameras are banned presents all the wrong messages.

Oakland’s Color Lines

I’m reading W.E. DuBois right now. I was led there through West and Asante. I blame them for raising my curiosity enough to want to buy and read some very old, very intense, very amazing writing from a long way back. While I wouldn’t recommend The Souls of Black Folk to most readers, it is some stunning work and paints such an incredibly detailed picture of a world in the south one hundred plus years ago.

I’m working on some redistricting problems for the City of Oakland
’s process and struggling to consider all the important aspects of building cohesive council districts that meet all the ideal requirements, it’s not easy. Contiguous districts, not breaking neighborhoods nor cracking the vote of communities of interest and much, much more needs to be understood.

For a simple exercise in “let’s just see if we can make a single, hills-bound council district in Oakland” I attempted to include only hills neighborhoods and those above the 580- the usual poverty split standard. When you do that you realize that you can get to a maximum population of perhaps 44,000 – we need to be closer to 55,000 in order to not have large variation- unless you can justify why that variation must exist. I had been looking at the data on the black voting population to see if this idea would break or include diverse communities and when I was done I panned down to look at areas to pull in population from the lower Rockridge areas and was stunned to see something that I’ve honestly seen hundreds of times on maps- Oakland’s Color Line running strong down Telegraph Ave.

The redder tones indicate high proportions of black voting age population in the population of citizens only.

Dubois refers to this concept as a Color Line that he observed in Georgia initially where communities of whites were completely distinct and segregated.  Seeing this data in Oakland in 2013 was a stark reminder as to how far we have not come from those early days of emancipation.

And that hills only district? Even including the entire hills, down to upper Rockridge still doesn’t give close to an even district population around 55,000….

Creating a new OpenData policy that works for Oakland

You often hear of collaborative models, real engagement and all that, but it often isn’t quite like that in reality. For once we have a chance to do something legit though. In Oakland. Urban Strategies Council has helped to draft a new policy for the City of Oakland to consider and with the encouragement of Council member Libby Schaaf we are making the draft open for any and all feedback. That’s right, you can suggest anything you like for consideration.

In a week or two we will host a roundtable/brainstorm at Urban Strategies Council to get together, hash out ideas and potential improvements and you’re welcome to participate in person.  The draft form takes what I consider to be the most relevant/strongest elements from policies in place in Austin, Portland and Raleigh. Why rewrite what others have done well. That’s what open source is about, and it works for more than software.

For the geekery, this policy is shared in Google Docs, not on GitHub. It’s not that we’re not cool enough or not down with GitHub (witness my amateur progress into that world, ha), it’s that we want something accessible to anyone for review, not just the uber geeks amongst us. We asked a few people on the edge of the dev world and had very resounding agreement that git would be a barrier, so we go low tech.

Have at it people- make it work for Oakland!

Draft policy.