About Me…

For 17+ years, I’ve worked in software and digital products as an Engineer, a Product Manager, and leader. I’ve been the consulting CTO and engineering lead for 20 or more startups. I’ve been a leader in Product for small and objectively large groups of Product Managers as an IC and as a Coach & Mentor.

In the distant past (ancient history), I was an actor, voice actor, math tutor, and owner of a wedding photography & videography business. Googling me is likely to return any number of related results (along with, apparently old Table Tennis videos).

I value products and companies that benefit people and society; ones that make us healthier, smarter, happier, and more productive. E.G. Health, Education, Sports, Games, Productivity, and Data.

One thread that carries through in my career is optimization and systematic improvement. I dislike repeating the same fundamental task too often, and so I find ways to simplify those tasks, systemize, optimize them. I typically work through solving a problem, and after I have learned what I can from doing so - find a new and improved solution or find new problems to solve.

At Fabric Interactive, that began with building progressively more modular and reusable CMS systems so that each implementation could be achieved more quickly and at a lower cost. Later, we developed systems and solutions that allowed us to launch fully functioning startup applications in under 30 days from idea to production traction of a fully working product - no vaporware allowed. Bespoke builds were quick, easy, effective, and comparatively feature rich.

At Rakuten Group, Inc in Japan - that meant focusing on People, Process, and Data when working as a Head of Product. Much of my goal there was to make my job redundant through empowerment, training, standards, and an empathetic approach.

I like making cool stuff with cool people.

When I’m “skilling up” I focus on ML/AI. My hobby at the keyboard is fiddling around on Kaggle.com. Aside from that, you might find me playing Table Tennis at a local club.

FAQ

How do you like to work with engineers?

My relationship with engineers is similar to that of anyone else on my team. We’re all equals as people, with different roles to play (this is true from intern to c-suite). Each team is different, and each role breakdown is different. In many cases, I may be the captain or the coach - and in some contexts, simply a player. In every context, we’re there to work and succeed together. All members are treated with respect, and ideas are welcomed.

How do you deal with conflict (in terms of direction, or choice of work) in your team?

It is often a part of my role to set up the systems and frameworks of decision making. Personally, I do so with an eye to avoid ego, authority, and emotional biases. We set up a transparent prioritization and decision making framework and make it known. Frankly, this avoids questions of direction or decisions on what work to do entirely within most teams. Couple that with a solid vision/mission statement, and collaborative strategy development to get full buy-in and then you’re golden.

Of course, that’s not to say I’ve not HAD conflict. I’ve made mistakes, tried different frameworks that failed, etc. What I outline above has worked for 10+ years without central conflict. So… yeah.

How do you deal with conflict (in terms of direction, or choice of work) with stakeholders?

In this case, we’re usually talking about stakeholders outside the team, but not our users. I.E other departments, or c-suite folks. That decision making framework we use internally? We share it. That’s #1. Following that, we do our best to understand the goals of the stakeholder. See my blog post on getting to the heart of their requests here: https://www.claytonkjos.com/blog/three-questions-to-get-to-the-heart-of-any-stakeholder-request. Understanding the goal & impact helps us align the request to our internal prioritization, and reflect back. Aside from that, practice gratefulness up front to any request and you can avoid lots of conflict in the first place.

You can’t always avoid conflict. Sometimes there’s no common ground… but that’s a much more situationally specific topic.

Do you have a favorite Prioritization Methodology?

Yes. At this time, I’m a big fan of modified forms of CD3 (Cost of Delay). It has the benefit of treating all requests from all directions equally by inverting the typical value assessment. Instead of asking what you gain from a task (which is often very difficult to quantify, tech debt alarm bells here), you ask what you lose by not tackling a problem. Mapping this over time allows you to maximize your value delivery. Flexing the muscle of asking the inverted question can make this fairly easy to do without getting hyper specific about the exact $ amounts. CD3’s often scary as people think you have to get very specific about the value - but most of the time that’s simply not true. In fixed resource teams, it’s really about optimizing impacts with those resources - so the $ amount isn’t terribly relevant. When considering new products / projects, you’ll want more care.

In the past, I’ve worked with HiPPo prioritization (I was at an agency, you know!), MoSCoW, RICE (and variants), ROI based, and Democratic (voting, buy a feature) mechanisms. All of these can work - but frankly, aren’t as effective as a simple inversion via CD3.

How do you like to design sprints / workloads?

I’ve been the guy trying to optimize sprint output. I’ve tried the rocks/pebbles/sand technique. Do. Not. Do. That. On many levels (more than this space), mixing in “quick wins” and distractions from your core objective is a really Bad Idea(tm). The natural tendency is to split focus onto easier tasks, with sprint participants breaking apart to do individual work. The culture is incentivized to shift from collaborative solutioning and support (such as pair work/programming) into one more like a production line.

Sprints are just units of time. The size is arbitrary. Get people focused together on a common objective and have them all support. Some people’s specialties won’t be fully leveraged on every objective. Getting them supporting each other in those cases, rather than searching for their own personal contribution is beneficial overall. If you don’t, you’ll end up with more “failed sprints” (absurd term), more parallel work, and a longer mean-time to deliver value. Bad behavior here results in a higher cost of delay overall, longer / larger deliveries, lower rates of experimentation, and a generally less happy development team (and client).