• Skip to primary navigation
  • Skip to main content
  • Skip to primary sidebar

Dion Almaer

Software, Development, Products

  • @dalmaer
  • LinkedIn
  • Medium
  • RSS
  • Show Search
Hide Search

Organization Design

Human concurrency

January 6, 2016 Leave a Comment


“There are only two hard things in Computer Science: cache invalidation, naming things, and off-by-one errors.” — Phil Karlton++?

Concurrency is hard. It is a world of trade offs and you often see some junior engineers thinking they have found the one true solution by adding in a caching layer to fix their performance problem.

I have been there. So many of us have. We need to be able to offer predictable and reliable scalability, and to do that we need to minimize bottlenecks. If we get this wrong though it takes more time to manage replication and invalidation and we have just created a potentially worse, and more complex problem.

As hard as it is to architect a solution that maps to product requirements and SLAs, I often think about how the same problem lies at the heart of organizations.

We have come a long way in how we try to scale humans:

We maybe took it a lil too literally?

But we may have a ways to go, even in 2016:

Thanks to Adam Tait and Stuart Argue for the inspiration and these photos 🙂

How can we predictably and reliably scale?

It is also tempting to grasp for the “simple” solution. If you have grown up around silicon valley for example, you think that the answer is talent density and small teams.

You can’t outgrow those pizza teams, you just need to split them up and you are all set!

However, it may not be that simple. This works just fine if you don’t need to communicate or rely on each other. Normally this isn’t the case. If you have team A relying on team B for some infrastructure (which is defined here as “the stuff you don’t want to worry about to get your work done”) then you could be bottlenecked on their velocity. If team B have multiple client teams then they have to prioritize and work out how to solve for that.

You can easily get frustrated here, especially if there is a lack of transparency around how prioritization happens. Do you have a way to offer up head count or resources so you aren’t just sitting there saying “when are you done” but are diving in to help? Is that even possible given the skill-set needed?

That is often the rub. Humans can’t scale in the same way as CPUs as each one of us is so different, and each one of us has very different software onboard 😉

It is so very easy to get into a log jam. Let’s look at a hypothetical example that you may have seen yourself.

Your company has a team that provides an infrastructure as a service. In general you want to use shared resources, especially if they have domain knowledge that you lack, and if by supporting you all of the ships that they support can rise.

It turns out that they want to support you, but they don’t have the resources to jump on this work. Now begins the prioritization game. Can you collectively get support for this work to be done?

There is nothing worse than being the small fry when it comes to these discussions. Let’s say you are a global company, and you are sharing a central payment service. A small country has a payment solution that is The Gold Standard where they are, so it is crucial to get it integrated into the Global Solution. But then a long comes the Big Gorilla. The country that is so large that one compliance feature goes through the ROI analysis and it knocks the small guys solution below the line. Ouch.

Well, screw it, just go off and do a custom build! We can move fast! Talent density ftw! It feels great while you do it, but you may have created a new cache to invalidate. Fast forward a little and you notice that there are now a slew of other groups that have done the same thing. Team members have moved around and some of those systems are hard to keep alive, let alone gaining features.

How will this play out in the long run? It may still make sense to take this path though, and as someone once told me:

“The life blood of a company is momentum.”

This is why scaling companies can be hard. It will be wasteful and you need to be OK with that. It will be messy and you need to deal with that. You can build a framework to help you make the decisions that you need to make as they come up, and then you need to paddle as fast as hell.


p.s. I am looking forward to seeing what comes out of Scaling Teams. There is a dearth of content on engineering management.

Primary Sidebar

Twitter

My Tweets

Recent Posts

  • I have scissors all over my house
  • GenAI: Lessons working with LLMs
  • Generative AI: It’s Time to Get Into First Gear
  • Developer Docs + GenAI = ❤️
  • We keep confusing efficacy for effectiveness

Follow

  • LinkedIn
  • Medium
  • RSS
  • Twitter

Tags

3d Touch 2016 Active Recall Adaptive Design Agile Amazon Echo Android Android Development Apple Application Apps Artificial Intelligence Autocorrect blog Bots Brain Calendar Career Advice Cloud Computing Coding Cognitive Bias Commerce Communication Companies Conference Consciousness Cooking Cricket Cross Platform Deadline Delivery Design Desktop Developer Advocacy Developer Experience Developer Platform Developer Productivity Developer Relations Developers Developer Tools Development Distributed Teams Documentation DX Ecosystem Education Energy Engineering Engineering Mangement Entrepreneurship Exercise Family Fitness Founders Future GenAI Gender Equality Google Google Developer Google IO Habits Health HR Integrations JavaScript Jobs Jquery Kids Stories Kotlin Language Leadership Learning Lottery Machine Learning Management Messaging Metrics Micro Learning Microservices Microsoft Mobile Mobile App Development Mobile Apps Mobile Web Moving On NPM Open Source Organization Organization Design Pair Programming Paren Parenting Path Performance Platform Platform Thinking Politics Product Design Product Development Productivity Product Management Product Metrics Programming Progress Progressive Enhancement Progressive Web App Project Management Psychology Push Notifications pwa QA Rails React Reactive Remix Remote Working Resilience Ruby on Rails Screentime Self Improvement Service Worker Sharing Economy Shipping Shopify Short Story Silicon Valley Slack Software Software Development Spaced Repetition Speaking Startup Steve Jobs Study Teaching Team Building Tech Tech Ecosystems Technical Writing Technology Tools Transportation TV Series Twitter Typescript Uber UI Unknown User Experience User Testing UX vitals Voice Walmart Web Web Components Web Development Web Extensions Web Frameworks Web Performance Web Platform WWDC Yarn

Subscribe via Email

Enter your email address to subscribe to this blog and receive notifications of new posts by email.

Archives

  • February 2023
  • January 2023
  • September 2022
  • June 2022
  • May 2022
  • April 2022
  • March 2022
  • February 2022
  • November 2021
  • August 2021
  • July 2021
  • February 2021
  • January 2021
  • May 2020
  • April 2020
  • October 2019
  • August 2019
  • July 2019
  • June 2019
  • April 2019
  • March 2019
  • January 2019
  • October 2018
  • August 2018
  • July 2018
  • May 2018
  • February 2018
  • December 2017
  • November 2017
  • September 2017
  • August 2017
  • July 2017
  • May 2017
  • April 2017
  • March 2017
  • February 2017
  • January 2017
  • December 2016
  • November 2016
  • October 2016
  • September 2016
  • August 2016
  • July 2016
  • June 2016
  • May 2016
  • April 2016
  • March 2016
  • February 2016
  • January 2016
  • December 2015
  • November 2015
  • October 2015
  • September 2015
  • August 2015
  • July 2015
  • June 2015
  • May 2015
  • April 2015
  • March 2015
  • February 2015
  • January 2015
  • December 2014
  • November 2014
  • October 2014
  • September 2014
  • August 2014
  • July 2014
  • June 2014
  • May 2014
  • April 2014
  • March 2014
  • February 2014
  • December 2013
  • November 2013
  • October 2013
  • September 2013
  • August 2013
  • July 2013
  • June 2013
  • May 2013
  • April 2013
  • March 2013
  • February 2013
  • December 2012
  • November 2012
  • October 2012
  • September 2012
  • August 2012

Search

Subscribe

RSS feed RSS - Posts

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

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

Dion Almaer

Copyright © 2023 · Log in

 

Loading Comments...