Dion Almaer

Software, Development, Products

The Pursuit of Taller Hills: Lessons from Football and Product Management

Management is a story of hill climbing. I started to reflect on this more while thinking about football management, a task that fits into more finite game theory.

With a Ted Lasso season running, and Manchester City winning a third English Premier League title on the trot, I hope you won’t mind a discussion of the best league in the world. It has triggered thoughts on how timelines and risk aversion ties to management.

The English Football Pyramid

The premier league has 20 teams, and this season a record 12 managers have been given the sack. The stakes are particularly high due to the workings of the hierarchy of leagues in the english soccer pyramid, as shown above.

ASIDE: The term soccer was in fact invented by the Brits! It came from associated football vs. rugby football. I’m not just being a yank!

The Premier League is known for its fierce competition at the top of the table. However, there’s more at stake than just the coveted top spot. The top four positions in the league standings grant entry into the prestigious and lucrative European Champions League. Additionally, teams that finish fifth through seventh may qualify for the Europa League or Europa Conference, depending on various factors such as winning the FA Cup or previous Champions League winners. While there are numerous edge cases, many top places in the league are highly sought after, making for intense competition throughout the season.

Then you have the bottom three positions. If that’s where your season ends, you are doomed to go down a division, known as the Championship. Financially, your lose out on all that the premier league offers (TV rights et al), and it’s such a sudden drop that you get an parachute payment to help soften the blow. This leaves a small middle of the division that doesn’t have to sweat too much. Things were in fact so tight this year that teams in positions of 12 to 20 were all fearing a drop. Hence the firings.

Compare this to franchise leagues such as the NBA, MLS, MLB, or NFL. If you have a bad season you get to regroup for the following year and, in fact, you may even have incentives to do worse if it means getting better draft picks!

↑↑↑ This is Graham Potter. He only lasted 9 months at Chelsea before becoming one of the 12 to go. He was heralded when he left Brighton and Hove Albion, where he had built an amazing system. The recruitment was fantastic, and he had a flywheel that would follow this pattern: bring in new players for ~cheap => bake them into the system => other teams buy them for !cheap => repeat. I can’t tell you how often they would sell a great player for great money, and you would fear that the team would struggle… yet it seemed to somehow get better as someone would stand to be counted.

He joined a Chelsea operation where they had spent hundreds of millions of dollars, with long contracts (to get around the fair play rules), but weren’t playing like a team at all. No system to be seen here.

Picture yourself in Graham’s position. The clock starts ticking on day one, and you need to climb your first hill. There is pressure to show results quickly, and you need to find which players work well together, and under which system. 4-4-2? 3-5-2? What are the patterns of play? Do you use a low block? It goes on and on. So much money has been spent on the squad, and the individual players have quality, so expectations are sky high.

↑↑↑ This is Alex Ferguson, the best manager in the history of the premier league (or is it now Pep Guardiola? 🤔). His first few seasons weren’t great, but times were different and the Manchester United owners stuck with him and his system.

He could take time to explore the hills. How can he get the most from his squad? How can he recruit to fill the gaps and mould the squad to the system he wanted?

Without this time, todays managers are stuck having to quickly pick a hill and run as fast as they can to the top, with a huge probability that it is a very local maxima.

Another topic that every new manager will have is: do you go against the traditional style of play of the club you join? change it to your style? or create one that maps to the players?

↑↑↑ This is David Ginola, who personified the traditional swashbuckling style of play of Tottenham Hotspur. Despite the team not having won any silverware for several decades, the fans have still been able to enjoy exciting, entertaining end-to-end matches.

The last three managers to join Spurs have not followed tradition, and instead employed a much more defensive base. When the team sees success with this change, the fans will grumble but hold their tongue, but as soon as it isn’t working… look out.

Ok, enough of this footy talk, how does this apply to management in tech?

Just as I fear for how little time football managers get to find the biggest impact, I often fear the same in corporate life. You often see a ~2 year re-org cycle, especially when there are trade offs around focus.

Pendulum vs Switchbacks

One common example is: when do you centralize a function vs. when do you group functions in a business unit? If you are in a function that feels the pendulum you are always waiting for the change. When don’t wrong, you feel like you are oscillating between two very known states without any learning.

When done better, it is more like climbing a spiral case, or switchbacks as swyx would say. This is where you take the strengths of each approach and bake them into the learnings.

Let’s take Developer Relations. When I rejoined Google in 2015, there was a centralized function. All tech writers reported through a functional tech writing chain. The same was true for developer advocacy, developer platform engineers, developer programs, partnerships, and more. Time was spent into solidifying what it mean to be great at these roles. On the flip side, if you thought of yourself more a part of the domain that you worked on, you weren’t as attached to the product and engineering world there. Consider yourself an Android expert as a Developer Advocate? Now you are in a hierarchy of DAs. How do the Android DAs, DPEs, Tech Writers, PgMs all coordinate? There was a special role to try to help bring things together. It was a tough role!

One of the first things I did was to switchback, and have one Android DevRel team, and eventually it went back into the Android product area itself to attach and integrate even closer with the teams there.

When joining a team as a new leader or manager, you have to make some decisions. After taking some time (hopefully!) listening the team, you will be working out what changes are needed. If you feel a rush to show impact, you may rush up that first local optima hill.

Through my own errors, I have learned to:

  • Listen to the natural feel for how orgs work at the company
  • Listen to the core problems your teams are facing, and think about potential solutions
  • Make some calls on what change solves real problems.

I am loathe to go against the grain of the company unless a) things are really broken with the approach, and b) I have a strong conviction that it’s time to actually create a new default for the company. I don’t want to flip flop, nor do I want to make changes that are surface level just because I am used to them.

If I was going into Spurs, I would very much lean into creating a Spursy team (hopefully breaking the mould of the losing!). When Manchester City got radically new management at the start of the 2000’s (and have allegedly done a fair amount of cheating I may add!) it was the perfect time to make a big change and create a new identity. The club needs to buy into this, and needs to allow the hunt for a better global maxima by giving the new leadership time.

The new manager bounce

Well, lcfc’s managerial bounce lasted 5 minutes.

One of the other reasons for the flurry of sackings is the myth of the “new manager bounce”. The theory is that the players will have some hope, and maybe will fight for their places more with someone new in charge. If the old manager had run out of ideas and left the team with no confidence, and the incoming manager has a series of fresh ideas, this can work! It doesn’t seem to be the case in practice.

Maybe the same happens in the office. I don’t know about you, but I feel like most of the reorgs I have seen are too frequent, and don’t occur when the ideas are dry. In fact, whenever you have a reorg you spend a lot of time revisiting items such as the strategy, the plan, and how you work. You require time to do the forming of the new way, and it takes time to get into your new stride. At times, a reorg has happened seemingly RIGHT when things were starting to click and execution was cooking with gas.

Too often real life feels like the CEO and the three envelopes joke.

Be thoughtful as a new leader, or a boss to a new leader, and make sure that everyone has the time to make sure they aren’t climbing the wrong hill.

/fin

Building a modern design system in layers

So often, when building a design system, we end up building something rigid that we will struggle with as time goes by. When this is done, we can try to evolve it well, and to make it so good that developers are somewhat happy with it even if they don’t like the rigid choices that were made.

This happens in all eras. Most recently, you will find many design systems that are React design systems vs. Web design systems that offer idiomatic React as an awesome option. As soon as you have made that choice you have locked in an audience and a lot of option value is taken off of the table.

Let’s consider that you are building a design system at a company that is on the path to becoming a 100 year company where you aspire to think long term. I contend that it makes sense to build your design system in layers that:

  • Have the wiggle room to move independently
  • A layer can even be replaced
  • Developers can swap out layers, especially those higher up in the stack

If I were holding a React design system today, and I was offered the opportunity to go back in time, I would swap it out for a layered Web design system.

What would this look like?

Let’s quickly talk about these layers.

Design foundational layer

Modern CSS can do so much these days. Start building out as much of the design system as possible with HTML and CSS. Components that used to be complex nested can not be a with some sprinkles. If you want some inspiration, check out the fine work of folks such as: Adam Argyle, Una, Jhey, and Josh W. Comeau.

Here you create your helpful guardrails via design tokens, your low level primitives, and your higher level components. I would consider using something like Adam’s Open Props as a strong foundation.

With some exploration, you will probably find that this layer gets you quite far these days, and with a nice story book playground developers will love to tinker as they learn it.

Interactivity layer

Next up you can loosely wire up the pieces via custom elements. This should be a relatively thin layer that brings to full life. You can choose a helpful tool such as Lit or Stencil to make it even easier.

These components run on top of the Web Platform, and are thus incredibly future proof.

Framework layer

Some developers will happily take the custom elements and use them directly, but most will probably want to use some bindings that feel idiomatic in the framework of their choice. There is no need for a holy war of “Framework vs Web Components!” They can happily work together these days. In fact, tools such as Lit have wrapper tools to make it easier to take your components and vend them as idiomatic framework components such as React.

Reach, Value and Future Proofing

With this approach you have set yourself on a solid long term path. Your work can now reach web developers that are choosing a variety of frameworks. If there is one thing we know about the web, it’s that there is healthy innovation and evolution on this layer. We can’t predict the future, but we both know that there will be new frameworks with significant developer share AND there will be a ton of apps running React and jQuery and … for some time. Both are true, so why not support both?

Now, you may be thinking: “We aren’t resourced to support all of the items in the framework later!” This is often true, however you don’t have to support them all, you can choose levels of support, such as:

  • First class / Well lit path: you make sure yourself that everything fully works end to end using code that you write and maintain.
  • Community support: with a well lit path or two out there, the community can take a look at the end to end solution, along with the layer below that it relies on, and create their own idiomatic bindings. The more you document the first class stack, the easier it will be for the community to take high quality code, with tests, and a spec of sorts and build something of high quality themselves. Make sure to elevate the work and effort that they put into it!
  • Individual usage: if there isn’t a library itself, a developer using their framework of choice can just use the custom elements to build on. Chances are one of these will jump up to the level of community support… especially if you incentivize and foster this.

I don’t know about you, but it feels like we are in a frothy time for the Web framework space. React has an army of developers, but there is some confusion on which direction to go. Will RSC fully pan out? When should you use Next.js or Remix?

This shines through when you see videos showing up putting forth points of view such as always bet on react! and I don’t hate react, i’m just moving on. It’s a time of change, right when there are amazing non-React options such as Solid, Svelte, Vue, Preact, and more. This is healthy, and having written web applications with more different frameworks than hot dinners that I have consumed, they can all help you deliver something great for users. So, it’s kinda win win.

It does make you think about…

Learn in Layers

Some wanna-be-gatekeepers have poo poo’d developers who come in and learn React first, and often skim some of the knowledge of the Web platform. There’s no need for the gate keeping, and this can be a great starting point.

That being said, I have always been a believer in Glen Vanderburg’s philosophy that it’s very much worth your time to understand one layer of abstraction below and potentially above you.

This means that you should have a solid understanding of the Web Platform APIs, as well as the core technology of JavaScript, CSS, and HTML. Often this naturally bleeds through, and although we are sometimes taught that a good abstraction doesn’t leak, some of the best abstractions are known as onion skin APIs when ”leaking” becomes a feature, an escape hatch.

ActiveRecord is a great example, where SQL isn’t hidden from you. Git has long built layers where you have porcelain and plumbing.

My good friend Dimitri has recently written about porcelains in the context of how we changed the API of Polymath with respect to talking to OpenAI. Instead of abstracting all of the fetch calls, we embrace the fact that developers probably know fetch well, and may want to use advanced features. We instead vend an API that understands the service via a request and response, so you end up with something such as:

While there has been a lot written in the form of “Web Components vs. $FRAMEWORK”, you find that this is totally the wrong frame. There are a variety of Web Platform APIs in the umbrella of Web Components, such as Custom Elements and Shadow DOM. If you take the time to learn this layer, you may find reason to use it with your web framework of choice. And if you do so, this knowledge will be durable no matter what other frameworks you use now and in the future. The browser moves slowly, and these APIs are here ~forever.

I recently worked with a team that deliver a high quality design system that is tied to React. If I could go back in time I would switch to this layered system in a second. It pained me to talk to developers that used the platform that the design system was used for but hadn’t chosen React. They want to deliver the same look and feel for users, so what do they end up doing? Many would view source and copy HTML and CSS and add interactivity. That’s a LOT of toil, and they have to keep up with changes in a painful manner with lots of diffing. If they could grab the lowest level, or maybe the custom elements with it, they would be off to the races in a sustainable manner.

Others felt they had to use React for these pieces, and hired consultants to do that work. This ate into their profits, and in dire situations could change the entire ROI of their solution (for small apps with a one or two person team).

I believe this design system will iterate and change over the lifetime of this company, that aims to be a 100 year one. You could argue that they are big enough to always make sure the React version is solid and updated and that developers have resources to keep with it.

Or, the evolution could happen at each level of the stack. Long time developers would understand the lower levels, and as they changed the highest framework level, they would be able to reuse that knowledge, use a community layer, or maybe the company has changed the first class framework and can use that solution.

If you have a modern design system, learn from my mistakes, and build it in layers.

That way a developer that chooses a different graph of tools from the subset of the options as Kent shows here, versus your exact path (which you will change too in the future), can play too.

/fin

Google A/I/O 2023: In Person Matters

I’m flying to Google I/O at Shoreline Amphitheater, a place that holds many great memories of times with teams and developers.

I wanted to come in person (thanks for the invite from certain Googlers… you know who yo are 😉 and once again unite with everyone.

I was nervous about the pandemic putting a dagger into the heart of in person events. When forced to be online only, we learned a lot about how to make that experience great, embracing the positives, such as crazy high production values and not having the constraints of:

  • “the person on stage” and often in one location (other than when we did Google Developer Day around the world on the same “day”)
  • The phenomenal reach and accessibility
  • The ability to measure
  • The reduction in cost.

Yup, events cost a lot of money, however if you consider the entire cost, such as everyone getting ready and building content, it isn’t like online events are free! Far from it, I have seen online event budgets that surpass those of in person!

One of the problems with in person events is that it kinda is hard to measure their value fully. It is my believe though, that a great event, with the right people there, can have a massive impact.

Reach is online, but deep connection and trust building can be 10x in real life. I remember my early days of JavaOne and rushing back to the hotel to try something out and bring the learning and opportunity back to the company and community. I felt an incredibly tight community, with information sharing going a mile a minute.

It’s great to find new developers and bringing them in to your community, and that first time at a conference may do that for you. I was just speaking to a founder that went to their first conference and even did the “old fashioned” booth thing. They were incredibly skeptical that there would be a positive ROI, but when all was said and done they left with new developers excited about their offering, which they saw in a large increase in traffic to their website, and actual adoption of their product.

Bringing in new developers, making sure their onboarding is frictionless, and getting them ramped up, is important. But, it’s hard to overstate the importance of feeding the inner circle of your ecosystem.  These developers are your external advocates. They are shipping and growing today. They deeply know how your platform works, often more-so than many of your internal hires!

Even in the pre-pandemic days, magnitudes more people would watch the content online than in person. It’s not about having huge numbers at the event, it’s about having the right folks there new and old.

Getting together to maintain a full trust battery all around is very much worth it.

I’m looking forward to filling mine up at Google I/O. See some of you there!

/fin

The right thing to do, is the right thing to do.