And I’ve used something like it often over the years to explain what I mean. I’ve also seen some very Dilbert style versions where the boss has a whip instead, and they’re meant to imply that bosses are less useful than leaders. That’s not at all the direction I’m going for. I just want to call out the difference because they’re both useful roles. Many times it’s the same person filling both of those jobs. But it doesn’t have to be. Understanding the difference, and how to both encourage and express leadership without needing to be the boss is a great skill to try to build.

So if you want to keep building instead of moving over to manage people what can you do to make sure you’re continuing to scale up how you impact your organization? I’m going to tilt this very much in the technical team direction cause that’s just what I know the best. But a lot of it applies pretty broadly for any individual contributor role.

Two of the most major areas that make management the default are planning and team development. It’s hard enough to come up with the plan for a technical project at all. But then trying to guide the team through the practical aspects of shifting goals and requirements, people leaving and joining the effort, and figuring out some realistic milestones along the way that actually reasonably reflect progress - that’s hard enough to do if you do understand all the parts of the system in detail. If the person who has to manage that isn’t able to just roll up their sleeves and dig in when something doesn’t seem to be working, the whole process gets hung up very easily. So the default becomes having someone who’s familiar with all the technologies also run the project.

That’s not the only way to solve for that problem though. If the person running the project can get enough of the right bits of info it’s not necessary to keep digging in to get answers and unblock things. Good bosses have their processes and techniques they use to make sure that happens. But there’s still plenty we can do to make sure that works.

Most important is to try to understand the right level of detail when sharing updates. I’ll often see junior folks pour tons and tons of info into their status updates thinking that will help with the planning. It might at certain times and for certain projects. But mostly that’s just noise if all we really need to know is that things are on track. Learning how and when to call out things that might be a problem is a great skill to try to hone. And a lot of the ideas overlap with the horsepower and torque points. When your call outs on issues are really representative of points that need special attention and not just things you might disagree with, you’re doing a great service to the team as a whole. And it takes just a few instances of that to be able to strengthen trust with everyone.

The other assumption that pushes teams to want to move senior people to management is that being someone’s manager is the best way to share knowledge. This one has always been particularly frustrating for me. I almost always see the opposite. People who were fantastic team members that I got a lot from collaborating with have all their time taken up with the new parts of their job. And when I talk to the people they’re directly managing, expecting them to be loving working for someone I know is technically very strong, that’s often not the case.

Of course there are tons of ways to help out your team by spreading some knowledge around outside of the default channels. But just like in the project management context, it’s all about making sure it’s the right info at the right time. It’s not super useful to your team if you just read the gang of four Design Patterns book and you want to take every single possible opportunity to lecture everyone about the top three or four patterns that would probably apply to what they’re working on. It would be super useful to them to hand over an article that you saw about how to configure netem if they’re working on tracking down a bug that seems to only happen over spotty networks.

It’s fantastic if you want to find some ways to share things you love working with and have deep knowledge of. Find the right opportunities to do so, and that can be a great level up for your team. But if you can manage to put aside what you really love and instead figure out the things your team currently desperately needs, that can be immediate significant benefit.

The good part of being political is about finding some common ground and figuring out how to reframe things to create alignment. I tend to think of it as the opposite of negotiating. I know it’s an oversimplification, but people say “you know a negotiation was successful when everyone walks away unhappy” because there is a grain of truth to it. While if you can find a political approach that doesn’t have to be the case.

Political problem solving isn’t something I see all that often in technical folks. We love to deal in objective data and hard facts. Finding a solution by doing something like redefining the problem or changing the context can feel like weaseling out of finding a solution instead of being creative. And it’s certainly not an approach that works for every problem every time. Sometimes you just don’t have enough flexibility to make a win-win solution out of what you’re working on, it needs to be a negotiation.

Looking for a way to side step a negotiation and find a win-win solution is a technique I find myself evaluating more often currently. I think as the size of the organization you’re operating in gets larger it gets more useful. But also, the malleability of the systems we’re working on keeps increasing as more tools and techniques based around AI become available. There are fewer and fewer objectively correct ways to divide up systems. That can be frustrating in certain aspects. But it can also open up opportunities to find quick alignment where you had to deal with negotiating before.

So if you find yourself in a situation where you’re about to explain the trade-offs between different approaches, or you’re sitting in a meeting with two groups talking past each other and just not converging on a solution, it could be worth running through some alternative ideas to see if you can instead get folks lined up. We have a whole bunch of new tools available to us currently, and sometimes the solution space you can cover with minimal effort is amazingly large. It’s a bit of a mental shift, especially if you’ve been building technology for a long time and have a bunch of established practices you need to reverse. But I think it’s a muscle worth exercising.

And if you want a much more detailed treatment of the evolving practice of building software overall, I recommend The Cathedral, the Bazaar, and the Winchester Mystery House. It lays out a great mental framework for some behaviors that might seem, well, kinda crazy. Until you understand where they come from.

As a startup person I tend to be a bit more torquey by default. But of course it’s not a completely black and white thing. While I tend to do things that need torque more often than horsepower, I try to be able to operate in either mode. When I do get the opportunity to just line up with the rails and let it rip I try to do that. It can be pretty hard to do at times. Picking at the edges of how people handle situations outside their default mode is one of the ways I try to separate really senior people from senior sounding people.

Being high torque isn’t just about setting up a new process. It’s about being able to make progress when there isn’t already consensus. And what you do when you’re in a situation where the team is moving counter to some opinion you’ve voiced is a great measure of that. When I’m interviewing someone I very often hear something like “I told them it was going to be a bad idea, and sure enough it didn’t work.” Hell, that’s something I used to say myself while I was still an angsty upstart. But that’s not a high value insight at all. Especially in a startup, where statistically speaking it’s easy to just say that nothing will ever work - you’re going to be correct a vast majority of the time.

My measure of your ability to contribute torque is based on what you did about it. This is something I try to dig for during an interview. Very often when I ask someone what they did when the team decided to go another direction after they gave their feedback, they frequently will say they just put their head down and tried to execute as well as they could. That’s alright, but it’s not a great indicator of torque.

I think generally people agree, especially in technical circles, that one of the marks of a great team member is someone who can voice a dissenting opinion, but then put that opinion aside and line up with the team once a decision has been made. But how you handle putting that opinion aside and line up with the team is the difference between a great team member and an amazing team member.

What am I looking for (and what do I try to do myself) in lining up with a team that’s executing on a plan that I consider less than ideal? It’s not just doing what you’re told to do. It’s trying to find the areas that you expect to be a problem and actively trying to mitigate the issues proactively while staying lined up with the overall direction of the team. That to me is the sign of a true senior operator and a fantastic team member. And it’s much more what I’m looking for than any detail about some technology you’ve used before.

I wanted to share this one both because it’s a useful tip for people to include in their hiring and interviewing. It can be hard to get a feel for someone’s attitude when they’re interviewing. But something like this, how they’ve handled their team doing something other than what they recommended, can be a great topic to have ready.

It’s also a great team dynamic issue to have a mental model for. This is one of those things that happens more frequently the higher performing your individual team members are. If you get a whole bunch of A players together it’s very likely at some point they’re going to butt heads. When that does inevitably happen make sure the “consensus” isn’t just lack of dissent. If you can instead drive for actual alignment it’s a game changer. And helping folks understand how to be a high torque contributor is a step I think can help.

Because of a long list of things that would only distract from the main point if I let myself get too much into them, I was at a fork in the road at the end of last year. I could either start up a new business or try to find myself a job somewhere. I was of course leaning toward the former. But also when I spoke to folks I kept hearing how horrible the job market is currently. I’m over 50 now, and particularly for folks in my age group I kept hearing that finding a good technical role is extremely difficult. Technical management not as much of a problem, but an individual contributor role would be different.

I certainly understand part of what folks see there. But I decided to go counter to the advice and at least try to find something inside an existing organization as an individual contributor.

Along the way I’ve found that many startup skills have translated insanely well to working inside a larger organization. That’s part of why I wanted to put a post together about this. For the older tech folks who maybe are having some issues, there might be a bunch of skills you have that you just need to figure out how to highlight. This is my partial list of things that surprised me in a positive direction when going into a more established company.

The set of skills around having a bias towards action work well in a number of different contexts. In the startup world when I’m working with a cofounder or talking to a potential customer I try to not just flat out say “no” to things. Interesting ideas come from all over the place. And even when something on the surface doesn’t seem workable, there’s often a core of interesting insight in the direction. I didn’t think the set of techniques I’ve built up for those interactions would be that valuable inside a bigger organization. But I’ve found the more often I apply it the smoother everything goes. I just treat everyone around me like my customers. I try to understand what they really want and not just what they’re currently asking me for. If they’re asking me for things that don’t seem to make sense I try to figure out what they’re trying to get done and how I can do something that progresses them in that direction. Everyone is my customer. The people managing the projects I’m helping with most obviously. But I found that the more I applied the idea all over, the smoother everything went. My teammates are my customers, my manager is my customer, whoever owns any of the repos I’m checking things in to is my customer. I try to find some way to make whatever I’m doing into something that helps them too. To my surprise it’s pretty easy to do after a few decades of startup life. I figured it might be hard to navigate the competing objectives in a larger organization, but I’m not feeling that part at all.

Juggling competing objectives feels almost trivial in a normal job compared to life in a startup. Sure, I have an actual task list to work my way through, with expectations that I track what I’m doing, contribute to reviews, handle a few async requests from other teams, keep an eye on what my coworkers are doing, and learn about the systems I don’t already know along the way. And I’m sure as I get more embedded in the organization the cadence of a bunch of those things is probably going to change. But I’m used to that list of concerns plus hiring a few new people, onboarding someone or getting an existing person ready for a new role they’re taking over, investor discussions, fund raising, customer onboarding, partner management, budgeting, product planning and tradeoffs, support, and some bit of legal review. Now, for the most part, I just need to get some bit of tech working. Sure, I might have to do it while the person who would normally help get it done is overloaded with other stuff. But compared to the average challenge I had to navigate before, totally doable.

And finally, the intensity is turned completely down. It’s easy to stay calm, cool, and collected when most of the problems you have are just that there’s a lot of work to get done. Sometimes it’s a bit of a scramble, and you might have to get inventive in how you stage things so that you can ship a partially working version while you figure out how to make the real version. But on my scale of intense projects that’s like a 1 or 2 out of 10. It doesn’t make it above a 7 until the current month payroll is hanging on the success or failure of the prototype you’re trying to hack together in the reception area of your next meeting. And if you can use that difference in your outlook to find a way to make the rest of the team feel more comfortable, or use your perspective to spot something that simplifies the situation for the rest of the team, you’re also getting a leveraged value from that. Helping not just keep your part of the project on track, but helping the whole team find a way through. I’m sure some of that is just from raw experience now, I’ve been doing this stuff for more than 30 years now. I should be good at it. But the startup side of the experience in particular seems to have cranked up the effectiveness of the methods I’ve ended up being comfortable with.

So for the folks out there who maybe are wrestling with the idea of what comes next. If you’ve been startuping, and you love your techie life, but it sounds like maybe you really need to get into management because it should be “the right thing to do” for someone your age. Please don’t accept that it’s what you need to do. The world still needs good technical people building things. Please don’t stop.

I’m unhappy with the way YouTube weights what shows up on my main page. I’ve subscribed to lots of channels I actually care about. I might not watch every video they put out, but I do care about what they post. If they post a few videos about things I either happen to not care much about, or maybe I already know a ton about so I don’t want to watch more, the algorithm decides I don’t want to watch them any more. They disappear. Instead I get lots of increasingly crappy videos. Shorts that are just movie clips with odd filters applied and garbage quality videos with clickbait titles and great thumbnails. I do like the serendipity of finding something new sometimes. But my main view should really tilt more toward what I’ve already said I want to watch.

It’s pretty easy to make a version that does exactly that with RSS, and as it turns out RSS is still available on YouTube. They even have the headers on most pages that make it easy to find the RSS feed without having to go digging around for it. So if you want to get the channels you care about from YouTube without allowing them to stop delivering the ones they don’t feel like giving to you - RSS is at least an option.

RSS reading options aren’t as numerous as they once were. But there are some good tools out there. Thunderbird has an option to add feeds into your inbox, and I believe Outlook still has something to handle feeds in a similar way. And when I looked at the App Center on my Ubuntu machine there were a few dedicated desktop feed reader apps that might work well. I wanted a project to play with recently, so instead of just picking up an existing one I made a very minimal command line reader called Feeder. It’s a command line tool that tracks feeds in a minimal SQLite database, and it just writes out an HTML page with the posts to read so I can open it in a normal browser. Works perfect for my use. I’m sure it might be too simple for others. But might be a good match for some so I figured I would share it.

One of the best places I found to get an overview is the Messari research report. As of right now (Nov 2025) that report has started to get a bit stale, but it was a great way to understand what some of the high level ideas where. There’s a bunch of pretty marketing heavy copy on the main XMTP site. The use cases and tools described on the project pages didn’t really match up to what I was seeing in the repos and code. And I never was able to figure out how to get Paragraph to send anything via XMTP.

I think this stuff is just the result of the project cycling at a pretty high frequency and working on new things. That did make it necessary to separate hype and froth from actual service though. When I saw the mini apps example showing Base and Farcaster on top of the Paragraph stuff I had run across initially I thought the project was up and running in full. I thought maybe I could get involved in some way, even though I might be late to the party. I’m not sure that’s the case though. I’m pretty sure everything is running on the testnet currently. If there is a mainnet up and going now I think it might just be getting used for some of the demo use cases. There is a mainnet ops epic on the project board, but I didn’t see any info about it in the docs. I figured maybe the mainnet stuff was tucked away behind actually funding an account, but my attempt to check out the funding portal all ran into errors or permission requests. So I assume that’s all very early stage. Which is all fine, it’s an early project.

Like when I had poked around with the Basic Attention Token initially, I just wanted to know if this was something I could just pick up and build with. I don’t think it would be for most of the uses I have in mind currently. Though I could certainly build something with it. I put the agents together to demo a simple notification setup, and it works. In order to be useful as a notification system there has to be a critical mass of people who drive their actions out of the inbox you’re delivering to. I’m not seeing that be the case. That’s mostly because of the target audience and not the technology. I’m currently thinking about some crypto tools for online content creators. Generally content creators want to lean on things that are already mass behaviors, not drive new adoption. I could be wrong there however. I could certainly see delivering a message about new content into the same wallet you use to pay for that content yielding better conversion rates for the content creator. But I assume if that was always the case the XMTP options in Paragraph would be more prominent.

I do love the idea of the project. I like the idea of interoperability by keeping the identity and inbox distinct. And messaging of some sort is a core service, even if we might have to figure out the higher value versions if there is postage in the system. I’ll likely keep poking around. Hopefully I can find a small area where I can contribute a bit while keeping an eye on how it evolves.

The Basic Attention Token is a pretty OG project. I suspect most of the folks who are interested in the project already know the broad strokes of what it was meant to do. But in case you somehow landed on this and you don’t already know about BAT, the super high level overview is that the token was meant to bring to the forefront the value exchange around attention that happens during advertising. Many of us don’t think about it, but when it comes to a lot of the business on the internet, we the users are the “product” that gets sold. It’s our attention (and the potential to divert that attention into commerce) that really drives most of the sites we use and think of as “free”. We normally aren’t aware of the big machine that’s trying to process our attention into dollars for someone else because it’s often intentionally hidden. And even when it isn’t hidden there are often so many stakeholders involved in what’s going on that it can be hard to unwind who is doing what and what data is involved. The Basic Attention Token was meant to simplify and make the value exchange explicit.

That was the high level pitch as it had existed a few years ago. And admittedly I haven’t followed it closely in the time since. I’ve tried to bring myself up to speed over the last month or so, and there might be some things I’ve missed in trying to figure out the current situation. But I’m pretty sure I’ve got the major parts right, at least as far as thinking about the token as a component of a development plan. The TL;DR is that the token itself seems to be in transition as Brave transfers to a different vision of how crypto and blockchain should fit into their overall strategy. If you’re interested in more detail than that I’ll try to lay it out.

The flow of BAT through the system is supposed to mainly be in support of creators. The central diagram on the BAT site shows a flow of BAT from both advertisers and users to creators. And the logo itself is meant to represent the relationship between advertisers, users, and creators in the system they’re trying to create. But it seems like that relationship has broken down under the current system.

In the original whitepaper the compensation paid out to the creators was meant to be an automatic outflow. The browsers would use directly instrumented time on property to figure out how much BAT should be directed to the publisher of a piece of content, and it would happen automatically behind the scenes. This was dropped as an option a while ago. I’m certainly not going to fault them for this no longer being the system in use currently. I could see there being some huge issues with this method of distribution.

In the absence of the automated contribution I did expect there to be a effective alternative. I pictured there being decent tools for supporting creators - maybe some tools for creators to drive the process on their own. In my mind that would be things like setting up ongoing contributions to your favorite creators, maybe tools for token gating some content, options to setup automatic BAT splits between multiple creators working on a collaboration. When I was looking at this part of the market a few years ago that’s the kind of stuff the crypto-forward creators were looking at. But so far I haven’t really seen evidence of activity on the publisher side. I’ve had a really hard time trying to size the outflow of payments to creators at all. There are lots of numbers shared on the BAT site, but amount of BAT paid out to creators isn’t one of the metrics. I would consider that core if the overall plan today is the same as it was originally.

So I just did some legwork. I figured of all the folks likely to have BAT contributions enabled, the blockchain and crypto media should skew higher usage. And since their audience is other crypto enthusiasts I assumed they would get some contributions. Figuring out how much usage there is for direct contribution is admittedly kinda hard. The BAT token was on the Ethereum chain to begin with, but it got bridged over to Solana to keep the costs down. That makes sense. And there are a bunch of custodial systems that were built into the Brave wallet to make it easy to sign up for the system and get users and creators onboarded. But what I was surprised to see was that the existing mechanisms didn’t smooth over the differences. I would often find someone who did have contributions enabled, but when I went to contribute to them I wasn’t able to because they’re on Uphold. That’s just broken. You have a user with BAT in the wallet you told them to setup, and a creator who’s asking for BAT to support their efforts, but it’s not possible to complete the transaction? If that main loop in the system isn’t working consistently it was hard for me to picture that the overall health was great.

The wallet I have setup on Brave is a direct Ethereum account though, so the few times I was able to get someone who was signed up as a Brave Creator and also had the right config on their side I was able to send them some Eth. And of course I could see the account I was sending to for those donations. There had been some other technologies in the mix at one point to keep users anonymous, but in this version at least we’re able to see each other for Eth donations. My system is obviously not scientific at all, but I just wanted to get something of a feel for if publishers were getting paid out at all. And from what I’ve been able to see, no. The few accounts I was able to get a bit of a view into had very low activity. In one case, before my donation the last deposit had been almost three years ago. And that was a pretty decent account with a lot of activity that I would have expected to be a highlight.

But the BAT token itself is doing pretty well in terms of price, so what does it really matter if the publishers aren’t ending up with the token? That happens because the Brave Rewards system has the token as part of the process. So advertisers on Brave need the token to be able to reward users, that puts the token in a pretty decent place compared to lots of others that don’t have any utility at all associated with them. That’s great for the price of the token, but not so much for the health of the ecosystem. For example, one of the big selling points of Brave is that it does a lot of ad blocking and stripping unessential content by default. (It really is a great browser by the way. It’s my daily driver browser and they’re doing great work over there, I just don’t think the BAT token is working). If your browser is stripping out ads that normally makes the content creators somewhat upset, cause they don’t get paid for the views of their content. If you have an alternative way for them to get compensated there’s a great answer to the content creators concerns. But if you’re both blocking ads and not really minding how the new system could be funneling them alternative value, there could be some issues down the line.

And there are some other efforts that seem a bit odd in relation to the core flow. Brave was encouraging a memecoin called Guano that rewarded folks for locking up their BAT. And they’ve made a partnership to allow for registering a .brave domain using your BAT. These things aren’t necessarily bad, but they don’t seem to be in service to the core mechanism the token is supposed to support. The cynical side of me would say they seem like the kind of thing I would do if I needed to increase velocity of the token and provide some utility exits for BAT that was pooling with users. But instead I’ll just say that these alternative ways to use BAT just further starve out the creators. There are a few posts on the community forum from creators who had been making some BAT for a while and have seem a pretty drastic drop-off recently. I wouldn’t be surprised if that drop-off correlated with the Guano launch. Why would users donate if they can earn from their locked up BAT? Especially when actually using the BAT to donate doesn’t even work a lot of the time?

So that’s my long winded version. Brave is open source by the way, the community seems to be pretty accepting. My hope had been that I would find something useful I could do to help out for the project. I know it’s not all on Brave to solve every problem on their own. However, with the core loop of the currency looking like it has stalled, I don’t think it makes sense to try to build with it. It seems like the roll of the token now is shifting to a new model. When I see the things like their domain registration partnership and native IPFS support I think maybe there’s another story starting to emerge around evening out access to infrastructure for folks underserved by existing providers. There’s been mention on the community calls of a revised roadmap coming up, hopefully that clears some of this up. I’ll cycle back around to it when there are some updates.

This is specifically for building a web app that authenticates against Google Sign-In. The web part of the setup is super simple to get working, and there are tons of examples and tutorials. Once I got to the phase of sending the token to a backend service to validate things got a little more rocky. First thing to note is that the key to use when verifying a token is shared across all services. Cause I had mostly been following info in tutorials I didn’t realize that for a while. I was trying to figure out how to use the info from my project admin UI to validate. It was only after running across another example of verifying a Google based token that I realized there was a PEM somewhere that held the verification key.

The info on that page says the Google API Client Libraries are the suggested way to validate a token. But honestly I can’t get the Go version working for this simple case. I thought I was using the libraries properly, cause they seemed simple enough to just validate a token. I even found a Stackoverflow sample that was almost exactly the same as what I had done. But I keep getting an error out of the library that the token is invalid. I actually think there’s some other dependency in that library. The error isn’t that the token I’m providing is invalid, but that the Google API Client assumes I have some kind of identity setup (that Stackoverflow answer says to “provide your Google credentials to your application”). I didn’t really want to figure out what that was all about. And those Google API Client libs are crazy huge in their Go implementation. When I did a go get on them it downloaded almost a gig of objects. So I started trying out some alternatives.

There’s a nice clean JWT library that looks like it’s still in pretty regular use. And it does work very well. It can just be a bit tough to dig up a good RSA based example of validation. There are some convenience functions in jwt-go that make it pretty simple to setup. But there are a bunch of examples around that seem to pre-date some of the convenience functions. So even the good samples can sometimes be a bit intimidating. Plus the tokens that you get back from Google embed a key id that you need to use to lookup the right certificate from their public listing. So I put together a sample using a current version of jwt-go:

This is just a sample mind you, you don’t want to be fetching a chunk of JSON over http in the key lookup function if you’re using this in some middleware. But the ideas are all there I believe: verify that the signing method is the expected algorithm, use the key ID from the token header to find the right verification key, and uses a nice convenience function to parse the PEM from Google very simply into a form usable as the return from the key lookup.

You should be able to just go run it as a standalone, pass in the token you want to verify, and you get back the claims from the token if everything worked. If things don’t work definitely use the tokeninfo endpoint before you dig in too much. That service can really simplify basic things, like pulling out the wrong string from a web response to use as a token. Not that I would every do that, no. But I’ve heard from friends that they’ve had that problem …

Mind blown. For some reason I thought those service containers were tucked away somewhere special and not exposed directly on the runner system. What a fantastic tool to have available.

Today I added a few tools so that it’ll easily build a workable image for the Meaty Skeleton sample with very little setup required. Here’s how to do it from a clean system (with Docker already installed):

I like the way it worked out. At first the Docker image was huge cause I did the tool download, build and cleanup as different steps. Now there’s a big and kinda ugly stage in the Dockerfile to download, build, install, and then clean up all as one big chunk. But the result is a relatively trim container that makes the startup a lot simpler.