Don’t believe the first story
Teams, executives, clients, and systems each tell part of the reality. They have to be checked against one another.
Background
I’m Charles Granet. I step in when Product & Engineering organizations need to evolve and the CEO needs an outside perspective able to go from the overall system all the way down to the code.
Computer science engineer, twenty years across product, software engineering, quality, management, and transformation.
My most intensive recent experience is in digital health. At Alira Health, I led Product, Engineering, and QA/RA for a digital therapeutics division, drove post-acquisition integrations, and restructured an engineering organization of about fifty people spread across several countries.
Before that, I worked in semiconductors, telecom, video, and startups. That variety taught me not to look for a universal method: what works depends on the company’s stage, the product, the constraints, and the people.
I still code and experiment. When needed, that lets me check the technical reality for myself.
Teams, executives, clients, and systems each tell part of the reality. They have to be checked against one another.
A team does not deliver in a vacuum: organization, product, architecture, quality, client, and decisions are linked.
Keep or shut down a platform, hire or cut, standardize or leave room for autonomy: transforming means deciding.
Development of a core EDA tool and experience in Silicon Valley.
Software SDK for carriers, team management, and technical projects.
Client-facing technical role and launch of VOD platforms.
Co-founder and CTO of a VOD platform built from scratch.
Company leaders asked me to assess teams, code, or organization before deciding what to do.
Product, Engineering, and QA/RA; post-acquisition integrations, team transformation, and healthcare platforms.
Diagnosing and transforming Product & Engineering organizations.
How I work
People have legitimate perceptions, but never the whole truth. I listen to them, look at what is actually happening, then look for the few mechanisms that connect the facts.
I can go from a conversation with a CEO to an architecture review, from a client meeting to a discussion with a developer. That range is only worth something if it leads to a better understanding of the system and to choosing the few changes that matter.
I’m not looking for an off-the-shelf solution. I’m looking for the one that fits the system I find.
First conversation
Tell me what has changed, what worries you, and what you have already tried. Thirty minutes is usually enough to tell whether a diagnostic makes sense.
Talk about your situation