James King

Looking for a job is different to working in an organisations with many teams.

For one thing looking for a job is more boring than having a job.

But one thing makes looking for a job much easier than having a job. My side of the job matching is visible, while the “hiring person” side is basically invisible. This is much simpler and easier to manage than the complex world of product delivery.

Put simply, I can see what I am doing and choose to take action or do something else. If I see a role by postpone applying for it, then I know I am the bottleneck. If I want to speed up I can use Claude and if I want to improve quality I can focus more attentively and take time to edit what I produce.

At the same time though, I have no visibility of whether someone read my resume or discussed it internally or much of anything else.

This invisibility impacts my “quick cycle times lead to quick learning” because I can fire off a resume and hear nothing back, or I can hear back a couple of weeks later.

So I improve my online profile and the information I submit for jobs with no feedback from real customers.

This is not ideal from a product management perspective. But at least it is a “visible invisibility”. I know I am not getting visibility of what is happening at “their end”.

It is the opposite of continuous discovery and good product management where we learn in fast feedback cycles but exist in a world of many moving parts we might not even realise we are not seeing.

Just like in a role in product management, I can innovate with the product, but I have the advantage of having access to the decision maker (me) immediately if I want to approve an experiement or a change.

I could change things today by offering to work as an interim executive, a volunteer, a part-timer, a contractor or permanent employee. I could add features to my offering by doing a course in governance or even learning to be a hit man. I could do a lot to tweak what is on offer and I should prioritise that carefully.

Being an interim executive is great but has a risk of being unemployed sooner than another role. Learning more governance is good for my long-term effectiveness but is unlikely to reduce the time to finding my next role. Learning to be a hit man is not going to help me find a role at all unless I enter a new market such as joining a crime family or taking up international espionage. Either way – I can make these decisions without delay.

What I was thinking though is that things are not just faster without dependencies. I also realised that nearly everything on my side is visible to me, which is a real luxury compared to working as part of a complex system.

And better yet, even the invisible bits can be tackled. If I want to improve my resume I can fire it off to many organisations and hear nothing, or I could share it with friends who work in the industry.

Sharing my resume and my plans will lead to real real feedback from these “proxies for the customer”, because they, like me, have hired for similar roles to the ones that I would apply for.

But in a real job, things are not so simple. In this situation you can get really busy, but the activity will not move things along if you are waiting for some input or decision. And you are almost always waiting on a dependency, pushing for a decision, or depending on communication with another person.

So you get good at managing dependencies, stakeholders and change. It is a real skill that comes with experience but can almost be undervalued.

For example, you can try to “get good” at managing dependencies by harassing people mercilessly, but that strategy is both less fun and less effective than it sounds.

On TV, leaders are often very demanding and they get all the resources they need because they demand them. They also tackle drama head on and keep moving at a pace that keeps the audience engaged. They yell, they take control and they run past all the people holding them back and they win. But in the real world they would just annoy people, muck things up and have to start again.

In the real world, people generally want to help, but they also have many more dependencies to manage, more annoying stakeholders asking for urgent attention and even other delays or pending decisions you do not see easilly.

So a real skill is to know when focusing on something will increase the speed and quality and when it is better to let things take their course.

I guess that seems like a vague statement, but they say you don’t appreciate something until you miss it or lose it. And in this case it is easier to see the complexity when comparing it to a simple environment where action leads to results and I can see the relationship between cause and effect.

So sitting here next to the trees in my backyard, I can operate at my own sustainable pace and appreciate the simplicity. And I can compare that to the challenge of working in a system where not everything is visible and the lack of that visibility has a real impact.

It is quite easy to see a bottleneck and focus on it in a team of one. It is also easy to think you see a bottleneck or delay in a team of 100. But generally, in a complex system, you are seeing the symptom of a bottleneck and not the real cause, and sometimes you are not even seeing the real bottleneck.

For example, at my last company, code reviews took a long time in some teams. So doing faster code reviews with AI will seem like a good idea if it means a code review takes less time.

In fact, it is a good idea. But generally, it was not the time spent on the code review that was an issue, it was the scarcity of experienced people who understood the code being available to start the review.

So getting more people experienced with the code seems like a good idea and it probably is.

But are still a couple of problems with that.

Firstly the desire to use a tool or process to fix things – “Use AI to make it faster” – can actually be a distraction. Pulling experienced technical people into meetings to decide whether to make AI code reviews better makes them scarcer on the ground. Doing that might cause them to take longer to go to a code review and make it harder to find time to mentor others to increase the people who can review code.

Of course, using AI to improve code reviews is the way to go and things like telemetry and automated checking will improve both quality and time spent on manual reviews. But it won’t in itself make senior staff more available.

So what might make the crew more available is better delegation, better decisions rights or more focused discussions when the crew do get together.

But then, what if the problem is not just scarcity of gurus? And what if the improvement or decay in our cycle time is the result of a change we made a month or two ago.

Guru scarcity will increase if we have a lot of turn-over but should reduce over time if we have stable teams and good senior staff who spend time coaching others. Even having people fix bugs will add to their understanding and reduce the overhead of code reviews. So we could see improvements now that are the result of one good tech lead creating stability in the team because people enjoy learning from her.

That change occurred a while ago, then people realised and then their skill increased and then we saw the improvement. Similarly the use of AI in code reviews might initially not have a visible impact and then a few weeks later it might be having a massive impact, but people are not mentioning it because it is obvious.

Or the code reviews are taking a long time because in fact the engineer was making “dumb assumptions” because they did not understand the way the customer used the product and the guru sent them back to ask questions of the PO and then make changes. If this happens then the delay in code reviews happens twice every story (or code package). And it might be the result of poor information coming into the team, which is fixed by neither the use of AI or the increased availability of coding gurus.

So I guess the conclusion is that, while AI is revolutionising the way we build products, there are skills and attitudes that still matter a lot. And the more complex the environment the more they matter.

The problem is though, the same as it was a hundred years ago. People fix and improve what they see and when they see a change they often assume that they understand the cause, when they are only looking at a symptom.

I don’t think I can put “take time to notice things and has a knack for finding invisible stuff” on my resume.

But I can say that it is a requirement of many senior product and engineering roles. It is part of the joy of the work and also part of the invisible value that motivated and experienced people can add.

So if it is not a resume thing, what is it?

Some of it is boring process and habit management. Making things visible, being transparent and looking at the system are all ways that uncover previously invisible delays and bottlenecks.

Part of it is also curiousity. There is an Irish saying, or at least a saying I was told is Irish – “If you fall over, don’t look where you landed, look back at what caused you to trip”.

We could say that it is moving upstream or shifting left, but it is really as simple as remaining curious. Instead of acting on the symptom you see, you pause and ask how it came about.

More often than not, the slow moving tech lead who is not getting to code reviews is not actually a slow moving tech lead not bothering to look at code. It is a person in a system with many forces creating the existing situation.

And the better you get at finding where the hidden things are the better. It is often the time to make a decision that delays the implementation. It is often the distraction and not the work itself that is a delay. And it is often a lack of access to the right information or resources that causes the delay and the rework.

That kind of sounds obvious when you sit back next to a tree and ponder. But the art comes in paying attention and creating space to notice and ponder things when being pulled in 20 different decisions while multiple important things compete for attention.

`