Skip to content

My Ignite Presentation

Now for something completely different…

I participated in Ignite Boulder 40 in December 2019. I gave a talk about perennial vegetables.

It was a blast because it was largely out of my comfort zone. Yes, I’d spoken in public a couple of times, but in front of the entire Boulder theater? Yes, I’d given talks, but remembering everything and having no speaker notes? Yes, I’d talked for a fixed period of time, but communicating a cohesive argument in 5 minutes, with the slides advancing every 15 seconds?

It was a definite challenge and I was happy to be selected. I have no idea if every cohort works this way, but we built our talks over just 4 weeks.

Week 1: Come to a group session with only a rough topic idea (what you applied with) and talk about it for 3-7 minutes while being recorded. Feedback was given about the points that resonated for you to expand on.

Week 2: Write down your talk in 20 points and read it out loud. More feedback about timing and content.

Week 3: Put your talk in front of slides and give it to the group. I missed this one as I was out of town.

Week 4: Deliver the talk!

Of course, I practiced a lot during the weeks leading up to it. I was giving it in the shower, before I went to work, after I got home. Frankly, I was sick of it at the end.

But I’m glad I did it now.

Here’s the talk:

The Challenger Sale

I just finished reading The Challenger Sale, a book about consultative selling. I really appreciated its data driven approach. The book, written in 2011, outlines a new approach to selling that is fundamentally about bringing the seller’s business knowledge to bear to provide value to the seller. But not just value, value in a way that is both striking (something new the customer hasn’t thought of before) and that emphasizes the product the seller has to offer. An example they give is Grainger, who sells parts. Grainger did research and determined that a large amount of the dollar spend with them was for unplanned part purchases, which can be expensive in both purchase price and staff time. They worked with customers to take advantage of their sprawling inventory to better plan parts purchases.

They cover the different kinds of sales techniques that their research uncovered, as well as tactics to help people adopt “challenger” traits to become more successful. They also cover how to sell this methodology to front line sales managers.

Two things really stood out for me. The first is that every company needs to answer why their customers should purchase from them, as opposed to anyone else. This can be a hard conversation to have because once you strip away all the “innovation” and “customer centricity” sometimes you aren’t left with much. I know that when I was a contractor, I would have had a hard time with this–my best answer would probably have been “I’m trusted, available, knowledgable and local”, which kinda sounds like a copout.

The other great part of the book was at the very end when they talked about how these techniques could be used for the “selling” of internal services (IT, HR, market research, R&D). I found that really interesting in the context of larger corporations where some of the functions aren’t valued for strategic insight, but rather are order takers from the business. I have in fact myself been an order taker. It’s easy, but not as fun as being part of the strategic conversation.

Book Review: The Economists’ Hour

I recently finished The Economists’ Hour, a book about the rise of economics professionals in public policy. It focuses primarily on the USA during the 1960s-2010s, but it does cover some other countries (Taiwan and Chile primarily). It covers a variety of topics including monetary policy, deregulation, shock doctrine, and inflation. The book also focuses on personalities, from the more prominent like Milton Friedman to the more obscure (at least to me) like Alfred Kahn, and uses them to humanize the economic topics by framing the economics through the human beings who argued for and against them.

This book was a bit heavy going at times, but given the breadth of topics and time it covered, I found it pretty compelling. I lived through part of these times, but there were many things I learned, including the impetus behind US airline deregulation (the power of the airline industry relative to trucking and the success of intrastate carriers in CA and TX) and how Taiwan became an electronics powerhouse (a meeting over coffee and strong industrial policy). If you’re interested in the intersection of economics and government policy, this book is highly recommended. (Here’s a great podcast with the author as a bonus.)

Not delivering end user value

When you’ve worked in software for as long as I have, you have made mistakes. I’m going to catalog some here intermittently so I can analyze them and hopefully avoid them in the future. I may change identifying details or use vague descriptions.

When you interact with a client, especially if they are knowledgeable about their domain, it can be hard to come in and seize the reins. You want to be respectful of what they know and what you don’t. But at the same time, they hired you for what you know, and sometimes you have to stop hurrying forward and take a look around, especially if the project is not running smoothly. This is a story about a time when I didn’t seize the reins, and the problems that followed.

I was working on a long running project for a client. It was a bear of a project, with a ton of domain knowledge and some complicated partially done software. The team working for the client churned, including employees and consultants. When I was brought on, I didn’t have a full picture of the problem space and it felt like we didn’t have time to gather it. No one had this global view. Meetings with the client would often go down rabbit holes and into the weeds. The project was a rewrite and the system we were targeting to replace kept evolving. This original software system powered the business and yet didn’t operate with normal software development practices like version control. When looking at the code, it was unclear what code was being used and what was not.

But most importantly, other than diagrams and meetings, we didn’t deliver anything of value regularly to the client. We would spin in circles trying to understand previous work and take a long time to make small changes. We did write a testable new system and follow other SDLC best practices including version control, CI/CD and deployment environments.

This project finally started to turn around when we shifted from trying to replace the entire running system to replacing the smallest part that could possibly work end to end. This gave the team a clear vision, and showed the client a path to business value. We accomplished more in a couple weeks with this perspective than we had in the previous couple of months. This also let us commit to a real project plan and timeline. Unfortunately, the client wasn’t happy about the projected and past expense, and shut down the project weeks after the development team was starting to show traction.

Lesson: I wish we would have had taken the “smallest bit that would possibly work” approach from the very beginning. I wish I’d had the insight to call a halt and not continue down a path that was clearly not working a few weeks after observing it, not a few months.