gus.gray

Efficient vs Effective and Other Thoughts on Team Dynamics

2026-07-12T00:00:00+00:00

In this post I want to outline something that I end up pontificating on a lot and explaining to new leaders. The difference between what an efficient team looks like, what an effective team looks like, and the spectrum / tradeoffs between the two. Finally I also talk about what high performing teams actually look like.

Teams optimized for efficiency</h1>
Efficient teams are characterized by being able to operate with the most minimal resources necessary to deliver. They are lean and scrappy, with every resource fully utilized. They look great on the bottom line. They are one incident, pivot or complexity discovery away from disaster. The problem is they have no slack to absorb the unexpected and in our industry, there's always something unexpected.

Teams optimized for effectiveness</h1>
Effective teams are characterized by their ability to consistently deliver, on or under time, pivot at a moment's notice, and deliver something that hadn't even been conceptualized a short time ago. They can anticipate a need from a mile away, handle unexpected incidents, and still deliver their projects on time. They can do this because they have resources to spare. There's slack in their capacity which allows them to absorb the unexpected complications that will inevitably arise. They are also more expensive on paper.

The slider between effective and efficient</h1>
Costs, both hidden and visible, are the tradeoffs. The cost difference between the two can almost be thought of as an insurance policy. By running a team more efficiently, you're lessening your costs, but also lessening their capacity to absorb the unexpected. This will result in higher incidence of missed deadlines, unexpected outages, and of course, fatigue and burnout on the team. In contrast, a team staffed with greater amounts of unallocated capacity is going to look more expensive on the bottom line, but will be able to be more consistent in deliverables and less prone to disruption. You'll have a healthier, happier team, and that results in better, higher quality, outcomes.

What does a true, high performing team, look like?</h1>
So far I've talked about resourcing as a dial you set. But there's a separate question that resourcing alone doesn't answer: what does the team look like when it's actually working?
I've had the pleasure of working with many teams and a whole bunch of leaders of all calibers during my career. I'll tell a story, give an analogy, and then some further thoughts.
A story from my past, a tale of two teams</h2>
At one company I previously worked at, there were two teams for one mobile app. One was for the iOS version, the other for the Android version. One team was almost a dozen people between developers and QA. They occupied an entire room, were constantly in frantic motion, lots of visible running around late nights and weekends, trying to get things closed out by the last minute. The other team was significantly smaller, only two developers and a QA. They shared a room with another team, mine. In the morning they would put their heads together, talk for about 15 minutes, then get to work. At noon they went to lunch. If they needed to discuss something during the day, they'd stop working, turn their chairs towards each other for a few minutes, then quietly turn back to their monitors and get back to work. They'd usually leave promptly, right at 5, or earlier. One team was motion, smoke and fire constantly, the other was just smooth and quiet.
The drivers</h2>
Any fans of top gear? There are two episodes from 2012 that have always stood out to me as a good contrast. will.i.am and Matt LeBlanc. Both of them took a drive in the "Star in a Reasonably Priced Car" segment for episodes in series 18. This segment is where a celebrity would be given a few attempts to drive a track in a "reasonably priced car" and their best time was recorded. will.i.am was exciting. He made a bunch of mistakes but by his final lap he seemed to have it dialed in. Tires were squealing around the corners, hard engine revving etc... Really kept you on the edge of your seat. LeBlanc on the other hand, well Hammond straight up described it as "...boring..." LeBlanc's final lap on the track was almost boring to watch, almost just looked like a dude heading to the store to grab some milk.
Who's actually high performance</h2>
So in each of the previous cases, which one was the actual high performer? The one that was exciting to look at with lots of motion, smoke, noise, and excitement? Hammond said it best in his full quote about LeBlanc's best run. "The more boring it looks, the faster it often is." That's it. The best teams I've worked with have been straight up boring. They are quiet, unassuming professionals that just get shit done without a lot of noise and fuss. Things are organized, quiet, and move smoothly. Disruptions are handled as part of the standard process and there just isn't a lot of disruptive noises, emergency meetings, fire drills, or the other things that make for exciting TV.

Visualizing Diffie-Hellman in Rust + WASM

2026-06-22T00:00:00+00:00

The Diffie-Hellman equation was my first love in the world of cryptography and cybersecurity as a whole. So I think it fitting it be the first article for this new blog. Hopefully it won't be the only one.
I first came across it when a buddy of mine recommended I apply for a job at the company where he then worked. This company was heavily involved in the cryptography space, so in order to get ready for the interviews, I decided to read up on what was then a new-to-me concept. I checked out a copy of An Introduction to Mathematical Cryptography by Jeffrey Hoffstein from the library of the community college I was attending. I started reading it and working through some of the early exercises. Early on we get to a chapter on the Diffie-Hellman exchange. I stopped. I re-read the earlier sections. I read the proof again and walked through it myself step by step. I found it elegant, magnificent, and absolutely beautiful in the truest sense of that word. I learned it so well that when I went in for my interview I was able to even fully walk through the formal proof on a white board when asked a question about it. I did not get that job (hindsight 20/20, that's a good thing) but that was the first step that catapulted me into the career I enjoy today.
1. The problem: agreeing in public</h2>
The question Diffie-Hellman solves is actually pretty simple on the surface: how do you agree on a shared secret with another party whom you have never met and can only communicate with in a public setting? I promise that this shared secret being just a number will pay off big down the road (probably in a future post).
The answer as it turns out is math. Really cool math.
Our cast of characters are ones familiar to anyone that's read anything about cryptography. Alice, Bob, and Eve. Alice and Bob are our protagonists, Eve (short for Eavesdropper) is the antagonist.
Alice and Bob have never met and share no secret. Every byte they exchange is visible to Eve, who is recording everything. Somehow they need to end up holding the same secret number that Eve does not have.
That sounds impossible — and with more classic cryptographic techniques, it is. The trick is to pick an operation that's cheap to do and ludicrously expensive to undo.
2. The toy protocol</h2>
The Diffie-Hellman key exchange leans on the Discrete Logarithm Problem</a> — easy to compute one way (powers mod p), painfully hard to reverse. Everything starts from two public numbers, agreed in the open:
p = prime modulus g = generator (a base whose powers cycle through the group)</code></pre> Then each side rolls a private number and publishes one value: Alice: private a public A = g^a mod p Bob: private b public B = g^b mod p</code></pre> They swap A</code> and B</code> over the open channel and each finishes locally: Alice computes s = B^a mod p Bob computes s = A^b mod p</code></pre> With the textbook small values p = 23, g = 5, a = 6, b = 15</code>: A = 5^6 mod 23 = 8 B = 5^15 mod 23 = 19 s = 19^6 mod 23 = 2 (Alice) s = 8^15 mod 23 = 2 (Bob)</code></pre> Both land on 2</code>. Eve saw p, g, A, B</code> go past and still can't get there. Drag the sliders and watch it hold: