I am starting this blog because I have just closed something that took eleven years to build, and I have not yet worked out what to do with everything that experience left behind. Some of it is technical. Some of it is personal. Most of it does not fit neatly into either category, which is part of why I have avoided writing about it until now.
For over a decade I helped build a hardware and industrial IoT startup, working across embedded software, product architecture, testing, and eventually the less glamorous business of keeping a small engineering organisation alive. That ended. I now work as an embedded software engineer and technical lead inside a larger industrial organization, on connected products, testing frameworks, cybersecurity, and digital innovation. The move from founder to employee is not dramatic in itself, but it has been clarifying. It has made me notice things about engineering that I did not think carefully about when I was too busy doing it.
My work sits at an uncomfortable intersection: technology itself, the products it becomes, the organizations that build those products, and the business reality that decides whether any of it survives contact with customers, regulators, or budgets. I have spent most of my career assuming that if you get the engineering right, everything else follows. I no longer believe that, or at least not in the simple way I used to. Good engineering decisions get undone by bad organisational ones, and organizational decisions are themselves shaped by things engineers rarely get a vote on: leadership, governance, maintenance budgets, human incentives, and regulation. I am interested in all of it, not because I have a theory that ties it together neatly, but because I keep running into the same questions from different directions.
There will be posts about embedded systems and software engineering as a discipline: architecture decisions, testing strategy, the practical differences between unit testing, SIL, PIL, and HIL, development process, and tooling for connected industrial products. This is the part of the blog closest to my day job, and I will write about it the way I think about it at work, which means with more attention to trade-offs than to elegance.
There will also be posts about engineering judgement, which is a slightly different thing from engineering skill. Building the right product is not the same as correctly implementing whatever requirements you were handed. Some of the most technically sound solutions I have seen were still the wrong answer, because nobody had properly interrogated the problem first. I want to write about that gap, and about systems thinking more generally, including the uncomfortable exercise of challenging assumptions I have made myself.
Alongside that sits a set of posts about engineering organizations and leadership: how technical issues get communicated, or fail to get communicated, to people who make decisions; how ownership and accountability actually work once a team grows past a certain size; governance and tooling approval processes that look bureaucratic from the outside but usually exist for a reason; and the genuine differences between how a startup operates and how a larger corporate structure operates, having now lived through both.
Then there are the personal posts, which cover building and closing a startup after eleven years, and the particular difficulty of knowing whether you are being persistent or merely stubborn while it is happening. I am currently writing about that closure directly, and about what changing my mind, repeatedly, over more than a decade, actually looked like from the inside. I am putting personal and technical writing in the same place deliberately. The professional decisions I made were shaped by who I was and what I believed at the time, and separating the two would make both less honest.
The last recurring series is the one I am probably most looking forward to writing: imagined futures tested against reality. Take an old vision of the future, domed cities, flying cars, underwater settlements, robot servants, whatever it might be, and ask what problem it was actually trying to solve. Then ask whether it is technically feasible today, what it would cost to build and maintain, who would regulate it, and how real people would actually behave once it existed. Most of these ideas turn out to be more interesting for what they reveal about their own era than for their engineering merit, and working through them is really the same exercise as evaluating a modern product proposal, just with lower stakes and better hindsight.
That is the thread running through all five areas: what problem are we actually solving, what are we assuming without noticing, is the solution feasible, is it sustainable once real organisations and real people get involved, and are we building the right thing rather than simply building a thing correctly.
What you will not find here is generic tutorials, recycled technology news, product promotion, or motivational writing about innovation and passion. I do not have a tidy answer to most of what I am writing about, and I am sceptical of anyone who claims to.
If that sounds useful or at least mildly interesting, have a look around, and feel free to disagree with any of it.
0 comments:
Post a Comment