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.
MBijon 