After leaving Protocol Labs last year I spent months diving deep into cameras and cinematography. In the process I learned a valuable mindset WRT tech.

Three of the most powerful tools for extending your local LLM today are Agents, Retrieval-Augmented Generation (RAG), and Retraining. My hope is that further understanding the basics of how these work and when to use them will help…

Software organizations need to evangelize the difference between effectiveness and productivity now more than ever. Don't measure software in terms of lines of code, but instead champion business value created.

I wrote no code, spent no time needing to futz with configurations, nor did I even really read any of the installation instructions to get this up and running. I copy/pasted some snippets, made no changes, and hit enter in my terminal. It all just works.

Organizations are constantly seeking ways to improve efficiency, foster collaboration, and maintain a competitive edge. LLMs are revolutionizing how teams collaborate, innovate, and operate. This playbook serves as your introductory guide…

This first book report is a book I recommend to everyone I know who works as a people manager!! It’s required reading for anyone who wants to improve team performance and the individual job satisfaction of their reports.

The Responsive Engineering methodology includes both organizational structure and development process. It was designed to scale engineering throughput as the team grew and it has scaled from tens to hundreds of engineers across three locations.

This is not just applicable to software. Everything I’ve described here likewise rings true for your whole org. I would posit that there are ways to turn this machine onto any dept. Anything your org does likely suffers from similar constraints at scale.

Your “up the chain” decision making overhead is like the serial portion of a parallel computation, capping any added resources’ effectiveness. The longer this serial process is, the less effectively you can increase velocity by adding resources.

The job of a software development team is to solve complex business problems with code. In this manner, if you can solve these complex problems without writing software, or by creating as little of it as possible, then you win at software engineering.

As product and engineering teams it can be tempting to simply believe if we were to “improve” a product as it was designed we’ll move the bar on our important metrics. The problem becomes that “The customer rarely buys what the company thinks it is selling.”

This is not just touchy feely stuff. There’s a lot of research and case studies around employee happiness, gratitude, sense of purpose, and friendships within your company that dictate how engaged an employee is.

To make this structure to work you have to live your culture. It’s important to be aspirational, but you must then “run your culture in production” in all your decision making processes. It is code, if you cannot operate within it, you must rewrite it.

We humans all have our own individual propensity for risk that makes us more or less likely than another to trust someone. Despite where someone lands on the risk spectrum, however, there are three primary indicators we look for when deciding who to trust…

Over the next 7 posts I’ll lay the groundwork I think is required to build a human operating structure that takes advantage of the “21 radical ideas” above.

Engineers need to base their decisions on facts. We have to be more than Python people, Ruby people, Node people, etc. Know and understand the tradeoffs between the tools you use, and choose what will work best for the goals of your project…

Your team is not a static entity. As it grows you'll find that you need more leadership as well as more role-players. I believe the key to doing this well is to look at all your hires not solely for who they are today, but where they'll fit in your company in a year, two years, and beyond.

I worked for a small startup with a great underlying product idea, but the founder, a former architect, wasn't willing to let users see the product until it was “done.” Because of this, the company eventually ran out of cash. It never got “finished,” so it was never released.

We’ve gone to great lengths to eradicate wasteful process, keep our teams light, tighten our feedback loops, reuse code, and simplify our approach wherever possible. This has resulted in the unprecedented velocity that companies count on when calling us.

Thats why it’s not good enough to just be good enough. You need to make it obvious to the world who you are. What are you passionate about? Snowboarding? Cool. Dubstep? Okay. Doing whatever it is we’re hiring for? Perfect!