My Competitive Advantage
What I Bring To Teams
I don’t avoid big, hairy, and complicated problems. I rush into them. I’m looking for growth—the qualitative kind—driving personal and team improvement, through quicker decisions and iterations. That is how I tackle problems, by creating a space to make decisions and learn from them. This process is not about making sure we make the right decision the first time.
In my experience, any team or group rarely contains all the information you need to get to the right answer. That means the way I work assumes we don’t have the answer as a first principle. Thus any process to find the correct decision must include information you don’t have available to you. The only way to get that information is by putting something out there in the real world—an approximate guess—and getting feedback on it.
I am comfortable with being wrong, but only for so long. Once you put a guess into the world, knowing it is wrong, we’re on the clock. The longer we don’t fix it, the quicker customers and users lose faith in our ability to get the job done. With an actual product in front of real users you have created space. A space for learning. A space for decisions. Purely theoretical discussions move slower, because you have no feedback, and thus no sure way to make hard decisions. Creativity shows up when you have constraints, not when staring into the clear blue sky.
Internally the team’s needs to be focused on engineering discipline. Like any kind of discipline it is hard, but simple. The team needs to be able to iterate quickly. This kind of development involves tradeoffs. As far as technology goes, the most important thing is a modern build environment where you can deploy a change in minutes (not counting how long any test suite might run). Without this ability you cannot create a culture of quick iterations and simple changes. Big changes are the result of many small changes.
Individually, in my experience the most important thing is getting each of the pieces to fit in your head. If you can’t load it into your brain you cannot reason about what is happening. I truly believe that every aspect of development quality and velocity revolve around this premise. Deciding where and how to break up an application into pieces is important. Too many small pieces, or pieces that are too large, and you cannot get it into your head.
There needs to be a structure to your engineering department that encourages iteration and experimentation. Those are the two biggest ways to learn what you don’t know yet. And I don’t mean just telling your folks to “iterate and experiment”, there are actual feedback loops that needs to be adjusted so that people can perform. Otherwise they are going to feel like they’re banging their heads against a wall. They need to know they have the support to change the organization. If we’re serious about iterating and experimenting, then the org is going to change.
All the recent movements in our industry, DevOps, Observability, and FaaS/”Serverless”, are all pointing in the same direction. They have all been enabling faster decision loops through faster deployment and the right sized pieces that fit into peoples’ brains. Seeing the broader landscape is important as we focus on the specific work we’re doing day-to-day.
