Funny thing about publishing free software, initially you want people to use it. But after they do, they may ask for free support or small problems in what you wrote eat at the back of your mind Could I be hurting someone more than helping?). How long should we support our FOSS projects & at what personal cost?
Around 2011 I published a collection of PHP XSS filters to a Github gist. The collection had started several years before that & evolved over time. At one point it secured a multi-national social advertising service Levi’s ran & was included in two minor CMS frameworks.
Five years later a security researcher found a pretty major flaw in the logic. I’m pretty happy it took five years to find that, but ouch it was a big security hole.
So … I’ve updated my xss_clean.php gist & contacted one project that still uses it. If you’re searching for an XSS filter, do me a favor & try HTML Purifier or the kses libraries. Currently & hopefully for a while longer, their creators continue to have enough time to keep them up-to-date.
Foursquare, Facebook, Twitter, and Yelp have all removed timestamped location-specific data from their APIs. Is there any location check-in data from a major site anymore?
All of these sites’ APIs used to have some form of user check-ins in their APIs. I’m not sure why check-in data is gone now … The sites could be hiding app-usage from other sites (or investors?). Or possibly it prevents new apps from building competitive features first.
Those arguments shouldn’t hold water, or I’m missing something. Big corporations can buy a firehose of data like Gnip & derive check-ins without needing users to manually do it. And, preventing startups from coming up with new ideas isn’t typical in tech. Helping a dozen different apps to build & test new ideas, then buying the successful ones is even easier now that Google, Facebook, and Twitter are public. Had someone built a way for dry cleaners to track each other’s check-ins and Facebook/Yelp/etc couldn’t afford to let their advertisers feel cornered?
Regardless of why. It’s unfortunate and counterproductive to innovation.
After all, there’s a cheap firehose of location data available from mobile ad networks. A few dozen check-ins tracked in an API? How about 16,000 devices tracked at the Iowa Presidential caucases. Integrating with all those mobile ad exchanges is a bit time-consuming, but the data is higher-volume and a heck of a lot cheaper than Gnip’s. After all, the mobile ad exchanges are providing this latitude/longitude data for free: It’s part of the targeting data provided *before* an ad impression is purchased.
Innovation is hard. Really hard. Unfortunately, many managers make it harder by stifling their best people with rigid roles that result in over-delegation.
Why managers do this makes sense in-general. There are few better ways to submarine any employees’ success than by stacking heavily-overlapping or conflicting roles on them. But as with all things product-related, should we follow a strict rulebook or look at the capabilities of the *individuals* on the team? Are we splitting roles based on the best use of staff skills, or based on some blueprint that came from another team?
In my experience, blueprints are nothing more than a starting line. Getting across the finish line takes a lot of problem solving, both in the engineering problems and getting the right people in the right places to solve those problems effectively.
A great example of rigid skill divisions causing problems is in Melissa Perri’s recent post, Product Management vs UX Design (good article & story, worth a read). However, Melissa’s challenge over where and how much product and UX should be divided is not unique to those skillsets. The same challenges can be seen between technical architect and product management roles. Between frontend and backend engineers … and so on.
As managers I don’t think we should force strict divisions between these overlapping roles. I also don’t think we should put a project at-risk by allowing everyone to have unclear roles. And finally, as the project or team grows we should rethink each individual’s roles regularly.
In particular, this is really important for startups. After all, they need multi-role, multi-field experts early on. Since most startups don’t have managers early-on, these people tend to be “naturals” and don’t have anyone telling them not to jump on new problems. But as startups grow, it’s important new managers can communicate to the high-performers if they’re needed to step out of direct contributor roles or to focus deeper on fewer areas. Sometimes this even means stepping away from something where a high-performer is 10% better than the new person who takes it on …so they can put time into the thing they’re 80% better at than anyone.
At larger companies the opposite problem tends to occur. Like in Melissa’s article roles can be so deeply divided that high-performers feel stifled. Or worse, some high-performers might find themselves without visibility into of knowing who to ask about problems that they’re still expected to solve. This is one of the core reasons so many big companies find themselves challenged trying to “turn a battleship.”
The best way to handle this problem, regardless of the company size, is for informed managers (ie: they know their teams and skills well) to have less-rigid team structures. Not *no structure*, but also not completely rigid ones either. And yes, this is hard. Spotfy shares great examples of embracing this “journey” and “variation” in the image above and their blogging on building a capable engineering culture. And if you like something a bit more data-driven, I think the judgement calls a manager needs to make are an example of Google’s early “PageRank problem”:
…early on Google needed deperately to spider more, more, MOAR. That way their algorithm wouldn’t link to an article about “this stock is a dog” when you were searching for info on “in-stock dog food”. But once they grew their network very broadly it became fragile. Then it could be “Google-bombed” by a few dozen people who agreed to use the same link-terms on their blogs (and worse, spam networks who ran 100’s of sites) – a search for “miserable failure” now recounts George Bush’s google-bomb probems well.
Between Spotify’s crammed infographic and equating this to a problem that challenged Google for years, team leaders have their hands full. But it can be done. This kind of standard-challenging approach and informed management is a big reason why companies like Google, Apple, and Amazon are “battleships” in terms of revenue, but running circles around the old guards of retail, info-brokering, and product development.
For simplicity-sake though, don’t worry about learning PageRank. Think of this like an 80/20 rule when managing: 80% of the time a clear role is probably best, but 20% of the time picking the *right* person and merging two roles is best. And, when in-doubt ask yourself if the person you’re thinking of for a role is a high-performer. If they are, have a chat with them and ask if they’re prepared to step up and take on the challenge.
Odds are your high-performers will say yes (or at least point out some nuance you missed and suggest an even better solution). Then announce to the rest of the team what their sprint, product, or new title expectations are & why they’re pretty uniquely suited to “this problem, right now.” Clear challenge. Clear expectations. Clear timeline for revisiting it. Clear communication. And, odds are that high-performer is going to be happy being asked to step outside of a rigid list of rules.