richie5um

Thank you for sharing. As a T1 diabetic too, I was reading this nodding my head all the way through.

“Most diabetics have CGMs these days” - not where I come from :-(

Agree. They came out of the gates with a really well put together chat app, that made a massive impact. Then, basically, didn’t advance it beyond that. It is still great for chat, but Teams is sooo much more useful for the virtual office, and discord waaay better for social. Slack is in an ever decreasing middle zone.

I love the book ‘Back of the Napkin’. He talks about identifying what you are trying to present, and marrying that to the diagram you draw. I’ve used those approaches many times in tech/product descriptions.

Couldn’t agree more. It must have one of the worst usage-to-enjoyment ratios of any site.

100% agree. I realised many years ago that to try to restrict/fix requirements was futile - or, you can try, but to what end. It’s like swimming upstream.

The hard part is that being adaptive to change increases the complexity exponentially with size (of project, of people, etc...).

Therefore the only way out of this formula is to reduce ‘size’, and iterate with (/alongside) the customer (even if that is an internal _customer_).

It is basic math(s).

I think the high-level summary of the article is ‘fire-and-forget development’ - ie producing features, but not measuring impact/benefit/usage.

I’m not convinced ‘feature factory’ in itself is problematic (definition not provided). There is no problem (IMO) in optimising to ship features - as long as the overall approach is to measure impact/benefit/usage and then learn and iterate.

Agree. I much prefer the term ‘product engineer’ to all previous titles. It shouldn’t be a cargo-cult switch where everyone starts calling themselves one, but it is by far the best title as a guiding principle to what we are meant to be doing.

Also, I think we are going to see further evolution in the software industry where the current middle-mgmt layers get wiped out. You are either contributing directly to the product - and you can easily measure that - or, you need to get out of the way.

DevOps is a drive to reduce the number of vertical organisational ‘layers’, ProductEngineering would be a drive to reduce the number of horizontal organisational layers.

IMHO.

Yup.

Business benefit supersedes customer benefit. Always.

This story is similar to mine. I really don't want to have lots of subscriptions, but I use 1Password sooo much, it is a clear winner for my money.

Fair response - my assertions were a bit extreme :-).

You can use process to force change, but, personally, I think a strong manager/leader would aim to resolve these issues irrespective of the process. Also, and I think this is why so many complain about agile, is that it is used to change these types of behaviour and is then seen as ‘the bad _guy_’.

My personal view is that the process should be aligned with your business, not as a tool to fix people challenges.

The 15 min daily catchup is invaluable irrespective of your overall process.

Easier said than done though :).

Happy to talk further and learn from your experiences. Thanks.

That’s a list of poor engineer attributes, which need to be addressed via conversations. Not impose a process in the hope that’ll fix them.

Really liked this article.

I liken software methodologies to cooking recipes.

On one end of the scale you have a highly skilled and experienced chef, who can craft a great (requested) dish with a variety of ingredients and equipment. Knowing how to adapt and what to add and when. This works well, but requires a heavy cost (experience) and is, from the outside, difficult to follow and control.

On the other end of the scale you have fast food. A strict process and fixed ingredients that ‘just works’. Those involved in cooking have very little knowledge of why, and are almost certainly not able to adapt. This works well for scenarios where you exactly know and control both the input and output.

A skilled chef can ‘codify’ their recipes, but this results in a specific description of what to do, and not why. Thus marginalising the adaptability.

In my experience, most software engineers are trying to attain the skilled chef role. While most _managers_ want the fast-food style predictability. With the ‘process’ being the battleground.

The best process is where you - a complete multi-disciplinary team - make as quick iterations as possible, learning as you go. But, always knowing where you are trying to get to (and why!) and constantly adjusting accordingly.

Good luck out there.