Hi there, I'm software engineer and technical leader based in the UK. With 20 years working in IT and software development, this site contains my thoughts...
Amanda has submitted the report late and what's there isn't really up to scratch. Kathy reads it with her head in her hands, unsure how this could have gone so wrong. "Last week, it was that Amanda wasn't following the process, and now this!" said Kathy, adding "I don't know what to do!" Kathy and Amanda are obviously not real names, but this is a facsimile of a real scenario I was asked to advise…
A question many of the engineers I've worked with over the years face at some point or another is: "I feel stuck, I want to progress, but I'm not sure how; what would you recommend?" Talking In Titles My longstanding approach has been to try and outline the nature, responsibilities, and accountabilities of roles using job titles as an anchor but I've always found this approach somewhat lacking.…
I'm publishing this as a work-in-progress piece to get some feedback, expect some revisions. An aspect of product engineering leadership that I've struggled with over the years is right-sizing development effort, solution complexity, and business impact. Done well, this adds significant value for businesses and customers alike. Doing this well, however, is more art than science. I've used this…
I drew this graphic after reading Richard Rumelt's excellent book Good Strategy/Bad Strategy in order to explain the concepts of strategy to those I coach in technical leadership. It distils the essence of the model Rumelt puts forward to help guide the process of working a strategy. Challenge proceeds a Strategy Strategy is fundamentally a response to challenge; you need to understand its shape…