I think this is a valid approach, but success is contingent on working with product-minded engineers [0]. I consider myself to be one, so I'm a fan of this approach. There are also many engineers who aren't product-minded, and they might prefer working in a culture where their job is to focus on execution.
Agreed. In that situation (following tfa's language) the product owner must either be an architect or be besties with one. A hoard of relatively unskilled laborers is not going to produce a cogent product otherwise. Then, what are you left with? The architect is leading the charge.
It's also good to take a step back and recall that all of these prescriptive, brand-name models for making software are, in fact, products in and of themselves. Their purported aim is to improve software, but what they really do is sell books, conference tickets, and consulting services.
You're describing symptoms but you don't know how to address them because you don't know the cause. Dig deeper. Ask folks if they feel a sense of urgency. If they say no, ask them why. Once you understand the root of the problem you'll be able to iterate on solutions.
According to The Phoenix Project [0], if you can form a model of how work flows in, through, and out of your team then you can identify its problems, prioritize them in order of criticality, and form plans for addressing them. The story's premise sounds eerily similar to what you're facing.
I did this! I founded EUI [0] at Elastic and helped teams adopt it. I attribute success to a few factors:
1. Publish components, not styles. This has been rehashed in other HN threads, but the idea is to provide Lego blocks to help engineers build UIs more quickly. This might be out of fashion with Tailwind adherents but we found success by treating the framework's primary interface as React/Vue/JS, not CSS.
2. Be transparent and receptive. Share your goals with consuming teams and ask how you can help them. They might ask for specific components or might ask you to help them convert a UI to use the library. By demonstrating that you and the library are there to serve (as opposed to dictate) you'll earn goodwill and your work will have more impact.
3. Have high-quality components. This applies to the UI design (both how the components look and how they behave) and software design. Are the props intuitive? Do the components compose well? We were fortunate enough to have a strong design and engineering team that did well on this points.
4. Seed the consuming codebase. Patterns in codebases propagate because engineers like to copy/paste. For example, start by migrating all buttons in the consuming codebase over. Then migrate over all forms, modals, and so on. It also helps to take a vertical approach, by migrating a single view entirely over to the library, or building one from scratch. This can get people excited about the library because they can see and experience the end result.
5. Ensure compatibility with the existing codebase. Make sure styles don't collide, make sure the underlying JS libraries are compatible. I chose React for EUI, but the consuming codebase (Kibana) was Angular. We made the decision to convert Kibana to React too, but there was a temporary period where we mounted React components inside of Angular. We needed simple guidelines to support the engineers who were doing that.
1. Documentation should be more than half of your team's time. If it's well documented, and has copy/paste content, people will use it because they are lazy and you gave them the easiest solution.
2. Don't think of yourself as building the UI library only. Take the time to work downstream in the product and help the product teams convert to the new stuff. If you're seen as friendly and supportive, rather than adding more work on a team, it makes things easier.
3. Constantly show off your work in large gatherings. Most folks aren't aware of cool stuff you're doing or why it might be useful. Show, don't tell.
These things fail when the upstream library team things they are passing things over a wall (npm) to a consumer. Dogfood it by building the product alongside the teams.
Hey Dave! I think your great design was a big factor in incentivizing people to use EUI. When folks can see how much of a boost the library can give a UI, they'll _want_ to use it.
“ I chose React for EUI, but the consuming codebase (Kibana) was Angular. We made the decision to convert Kibana to React too, but there was a temporary period where we mounted React components inside of Angular.”
This is my life right now. Glad to hear someone who has done this managed to survive the ordeal :D
I appreciate your points. Can you share more about how you interacted with other teams? Did you have resources to help implement the components into products? Did you use any tools or meeting formats to gather feedback and listen to needs?
Thank you! As snide mentions a few threads up, we built a documentation website for the library from day 1, which I think helped folks a lot. I'm not a fan of Storybook -- I prefer docs to present components in realistic situations, and to have code snippets live-side-by-side so someone can say "Hey this is exactly what I need" and copy and paste it into their codebase. For example, form docs should have an example of a complete form with validation, accessibility attributes, help text, and so on. This way the docs act as both an advertisement and as a resource.
Regarding tools, I recall a bunch of stuff. YMMV:
* A presentation to the wider team on the goals of the library.
* GitHub issues outlining technical design of the library -- this was useful for getting buy-in from tech leads.
* One of the consuming developers gave a presentation on how she had implemented a UI using EUI.
I think it just comes down to repetition and, as snide alluded, positioning yourself as a servant instead of an authority. Keep beating the drum, share success stories, and demonstrate that you're responsive to the feedback you're heading from the folks downstream. Good luck!
Sure, but do you think that's the reason why there is an interest in promoting diverse teams? For helping the people "grow up"? Besides, that's only true if the differences are relatively small, you can't understand and relate to everyone. You can obviously collaborate with them on a professional level.
I think mature individuals will be able to overlook significant differences in one another and focus on the outcome: helping the team and the business succeed. If I picked up a signal that a candidate wouldn’t meet this bar, I wouldn’t hire them.
Some of these guys hated each other, but, when the boss said "Go!" they put their differences aside, and all gave 110%, to meet the goal. They helped each other out, shared information, and never sabotaged anyone else's work.
Japan has the strongest teams that I've ever seen, but there's cultural reasons, and it would probably not scale to many other cultures. There's also tradeoffs, and many people would not be happy with those.
If you want a culture that is really good at ganging up on a problem, then Japan is a good bet.
They wouldn't dream of testing for "cultural fit," because that is assumed.
I think the point is that one group of people is imagining a change and saying, “That change will be intolerable!” And then another group is actually experiencing the change and saying, “Hey, it’s actually pretty good.” You won’t know how you really feel about it until you try it yourself, and speculating about the second group won’t net you any benefit.
I’m torn on litter. On one hand, I like a clean immediate environment as much as anybody else. On the other hand, throwing it in the trash is just hiding the problem. The garbage was still generated, and it still goes somewhere. If we were forced to confront the sheer amount of garbage we produce, maybe we would be compelled to produce less. But ah well… out of sight, out of mind.
Dunno, have you met people? Once the place is covered in trash, the next piece of trash has a marginal impact, so "we" wouldn't feel compelled at all. Just drop it wherever.
My very modest claim to "fame" is having founded the Elastic UI Framework [1]. My experience with these kinds of design systems taught me two lessons:
1. You'll iterate towards the most useful version of your design system in the least amount of time if maintainers spend time consuming it, and vice versa.
2. Code is the source of truth, in the form of the component library. It's an unhelpful fiction to treat the non-code design system (whether that's in Figma, Sketch, or wherever) as the source of truth. This is because people build out new parts of the UI by copying, pasting, and modifying the code of the existing UI. If you want to make a change to the design system, it has to go into the code to make a difference.
[0] https://blog.pragmaticengineer.com/the-product-minded-engine...