And from then it’s a mentoring role. The expert spends more time PR-ing and adding to the framework than building end product features. They build stuff that touches every feature.
Force multiplier is the game.
Because how good is the expert? They just built a bunch of stuff to enforce one approach; they're invested in it even if they're wrong, or even if the project changes.
The ideal is an expert who will be involved with the project, offering suggestions, providing a sounding board to non-experts working through issues, etc. Mentor and guidance, yes, but without first trying to lock people into a specific trajectory. And if ever the non-experts decide to do something different, -that's their prerogative-. Because it's they who will be dealing with the fallout if they're wrong. And unfair to make them deal with the fallout if they were right, and the expert was wrong. It's incumbent on the expert to convince them, not dictate.
Now the guy is gone and we are too invested to be able to fix any fundamental issues without incurring pain, so it's not done.
It's fine if people want to do something different: just first become an expert.
The other problem is that there aren't enough experts and how can they become experts without strengthening expert muscles. They have to practice and learn.
Depending on the distribution of abilities, what I've found to be give the most leverage is to convey a few specific design ideas significant for a particular project to someone on the project who can understand or at least commit to using them. You can check in from time to time and provide some input and clarity. Regardless of good intent on all sides, results still vary. But if done smoothly, everyone gets better at working together on high-level tech things and there's no resentment that doesn't fade away quickly.
Ensuring the non-experts understand their purpose is the role of the experts. NOT making the decision as to when to deviate. That's my point.
An org that leverages an expert to make others experts is an org that ends up with a team full of experts. An org that leverages an expert to make decisions for the non-experts is an org that is going to have a lot of issues in production, and likely high turnover.
Without it, you start out with a multiplier but end with a divisor.
Lone points of breakage such as a single visionary or the mythic 10x-er are not optimal for the product if the unit taking care of the product is a team or several teams.
1.) Mentoring is such a difficult aspect as an expert. I likely would have built up my expertise from a combination of my studies, my past work experience and my previous, extremely skilled mentors. I can't expect people to get up to speed simply through my mentoring alone - especially if I'm not a capable enough communicator.
2.) Experts like to retain their expertise, stay unique. Regardless of what idealistic scenario you have in mind, everywhere I've seen, experts are always very cautious to giving away ground. I've been guilty of it, especially when I knew that my unique expertise was responsible for my sizeable bonus check in an IB.
3.) Experts will not do all the grunt work you mentioned. They come with the expectation that they've been hired for their expertise and not to be another cog in the wheel, but the engine itself (for a particular project).
Ideally now, what you would want would be a team of generalists, and a small crack team of experts (or a lone wolf expert). The generalists set up the project, plan how to build the guard rails, etc, then explain it to the experts, then when both are up to speed, generalists build it out and give the heavy lifting work to the experts to take over from.
Converting a generalist to an expert is a time intensive process that has to be structured and well-thought out. It should not be for just one project, but should continue for multiple projects.
In sports they call that a Ball Hog.
Is software a collaborative effort or an ego trip for three people?
As someone else mentioned, their expert was spread too thin. I’ve had this happen to me, too, and the only solution I know is to give away (delegate) almost everything you can. If some part really makes you happy, hold onto that even if you could give it away. Not for ego, but for burnout. You need some reasons to show up in the morning, just like everybody else.
In some sense, that's exactly how top level frameworks like react and Django get made- experts build them to make it easier for the rest of us to write the business-specific logic.
When it's done well, I think it's a fantastic approach. I'm in a situation right now where I'm kind of that "expert". Not because it was planned that way, but because I was the only person on the project at the start. Now I've got a couple of young EEs working under me, and they do most of the development work while I sit in meetings for a good chunk of the day. I come in and help with the hard problems, but most of the day-to-day work is on them. It's working out great because it seems I got the structure relatively right (they've changed things a little bit as they've added new things I didn't think of, and I've reviewed and supported those changes)
The flip side is ${JOB-2} for me. It was a similar situation; an "expert" laid the foundations and then got pulled off to do other projects. There were two main differences between my current situation and that one:
- The infrastructure he put together was not great and full of footguns (e.g. accidentally implicitly double-encoding HTTP requests, bizarre cookie handling, etc)
- The code was hard to change because of how it was integrated, and the team didn't feel particularly empowered to fix it
- He was barely around (being assigned to something in a different building).
- He pushed back hard when people suggested that there might be problems with it and fixes required. Instead of facilitating and reviewing, he'd pop by occasionally, look at things that changed in his absence, and shit on them.
As I'm writing this, I'm reflecting on whether or not I'm contributing enough to the long-term development of this codebase, and I'm feeling relatively ok with the answer. Ultimately, this product is still my baby and whether or not it's successful is on me. Maybe that's the difference? I'm quite invested in the foundations I laid, and more than happy to help my team work through issues they find in it?
I think you're right that having skin in the game is critical. It's important to have real accountability, so if there's painful design flaws, the expert feels it.
But it's easy to think it should have been done differently and better when you don't have the perspective of the designer. I still vividly recall being a junior engineer and thinking the design decisions made by the "expert" were ridiculous, and talking with the expert, and finding out I didn't know everything and I was wrong. Thank goodness he was patient.
Google et all probably have lots of internal tooling and frameworks. Hell, react started as internal to FB didn't it? Does that count as a framework or as a product?
Lots of other companies have similar internal frameworks, probably with less resources devoted to them, but in the other hand with less use cases. Do those not similarly count as frameworks written by experts?
