Technical Content
Strategy
Where this fits
- Culture and people are already covered by Behind The Strypes.
- This deck covers three things: why clients choose you, how you deliver, and how you make it click for anyone. Not culture, not events, not employer branding, those are already covered elsewhere.
- ICT Strypes is a multi-client consultancy, and this shapes everything that follows.
Why we're not copying
the obvious playbook
- Some sector peers can name a client directly and show fixed, named teams, because they're structurally dedicated to that one client.
- Even without naming the client, that kind of content quietly reveals who it is.
- ICT Strypes doesn't work that way: multi-client, teams reshaped project to project.
- So the two pillars ahead are built around what's actually true for ICT Strypes: capability and process, not case studies.
Why clients choose
ICT Strypes
We want to talk about the specific technologies and problems you work on, like embedded systems and real-time software, without naming clients.
Capability shown directly, without revealing who the work is for.
How we
deliver
We want to show exactly how a project gets delivered on your team, from one person owning it end to end to how the architecture actually gets built.
The engineering work itself, not culture or values language.
Each story is one decision, one moment, one person, never a team, a client, or a finished project.
One Article a Month,
Explained Properly
Not a new rubric, an upgrade to Article Launch. One blog article a month, a carousel that goes one level deeper into the real technical explanation, not just the accessible surface, then sends people to read the full piece on the site.
The pace here follows how many articles the team can write, one a month is the goal we're aiming for.
This isn't a new idea
Other software engineering consultancies are already doing this.
Their engineers explain one technical concept at a time, on camera, no client names, no jargon overload.
Their Principal Software Engineers own each project end to end, from first client contact to final delivery.
They publish one technical article a month on their blog and announce it on LinkedIn, going one level deeper than the surface.
What we need to move forward
We already know some of the public technologies you work with: Linux, C++, real-time operating systems, embedded software.
We want to talk about these the same way freiheit.com and itsector do in the examples on the previous page, at a high level, without deep technical detail, just enough to show real expertise.
Can we go ahead with this? And is there anything else technical, specific to your work, you'd want us to highlight too?
A team commitment: one blog article a month, published on the site.