Sefism Tech Roles Beyond Coding Roadmap
A seven-stage roadmap into tech roles where code is not the main output: product manager, technical writer, developer relations or business analyst. It covers the landscape, the technical literacy all four need (APIs, JSON, Git, SQL), the core craft and professional-level work of your chosen role, a three-sample portfolio, breaking in and growing in the role. It suits students and early-career people who enjoy deciding, explaining or teaching. At the end you can do the core work of your role and have public samples to show for it.
7
Sefism · Oct 2026
49 to 54
Sefism · Oct 2026
173
Sefism · Oct 2026
4
Sefism · Oct 2026
6
Sefism · Oct 2026
Roadmap
Career Growth
Sefism
About 173 hours, 24 weeks at 8 hours a week
Beginner
Free
What this roadmap is
Tech roles beyond coding is Sefism's roadmap for people who like technology but want a job where code is not the main output. It covers four roles: product manager (deciding what gets built and why), technical writer (docs, guides and API references), developer relations (content, community and developer experience) and business analyst (requirements, processes and data).
By the end you understand the landscape, have the technical literacy these roles need, can do the core work of your chosen role, and have public work samples and a realistic plan to get your first role.
What you will be able to do
- Explain what product managers, business analysts, technical writers and developer advocates do day to day, and how they differ from project managers, solutions engineers and customer success.
- Read an API response, a pull request, a JSON payload and a simple SQL query well enough to ask engineers precise questions.
- Do the core work of your chosen role: a tested spec and prioritised plan, a requirements package with process models, a structured and reviewed docs set, or a tutorial, sample app and feedback report.
- Publish three strong work samples and run a focused search through internal moves, bridge roles and targeted applications, while spotting scams.
One roadmap, four paths
When you add the roadmap you pick a role, and stages three to five change completely to match it, while the landscape, technical literacy, breaking in and growth stages are shared. The number of topics depends on the role: 49 for product management and developer relations, 50 for technical writing and 54 for business analysis.
Who it suits, and who should start elsewhere
It suits students and early-career people who enjoy deciding, explaining or teaching more than building, and people already in support, QA or engineering who are thinking about a sideways move. The roadmap's first piece of advice is direct: do not pick one of these roles because you want to avoid code. Pick it because you like the daily work. Every one of them still asks you to read APIs, code and data every week.
If you want to build software, start with Programming foundations or a build roadmap such as Frontend development. If you like the customer side but want to stay an engineer, Forward deployed and solutions engineering is closer. If design is what draws you, see UI/UX design, and if it is data, Data analytics. If you are coming from a completely different field, read Switch into tech first for the strategy of a switch, then come back here.
Prerequisites and realistic time
No coding background is needed; stage two teaches the technical literacy. The roadmap adds up to about 173 hours across seven stages. At 5 hours a week that is about 35 weeks, at 8 hours a week about 24 weeks, and at 12 hours a week about 17 weeks. The first stage is a foundation stage you can skim or skip if you already know which role you want and why.
A student with 10 to 12 hours a week could finish the landscape and technical literacy in the first month, spend the next two months on the core craft with one real example, and use the following two for professional-level work and the portfolio, starting the search alongside the portfolio.
Someone working full time with 5 hours a week might take a slower route: one evening for reading and one weekend block for doing the work. The craft and portfolio stages (40 hours each) are where most of the time goes, so pick a small real example you can reach easily, such as a product you already use or an organisation you know.
Stage by stage
1. The landscape of non-coding tech roles (8 hours, foundation)
What "beyond coding" really means, what each role does, adjacent roles (project manager, business analyst, solutions engineer, customer success), who does well in each, the job market honestly, and testing your fit with small real tasks. You read ten real postings, talk to someone in the role and do one small real task this week: interviews and a problem page, a README, a five-minute demo or, for business analysts, one process mapped with five requirements.
Milestone: a one-page comparison of the roles in your own words, ten postings reviewed and one small real task completed.
2. Technical literacy (20 hours)
How software is built, agile sprints and tickets, clients and servers, HTTP, APIs and status codes, reading JSON, Git and pull requests, reading code without writing much, data basics and simple SQL, and environments, releases, feature flags and incidents. Business analysts add spreadsheets for analysis. You trigger a 401 and a 404 on purpose, open a pull request on a practice repository and write five SQL queries including a GROUP BY and a JOIN.
Milestone: a technical literacy notebook with five real API calls in Postman, three SQL queries, one pull request and a one-page client-to-server explanation of a product you use.
3. Core craft of your role (40 hours)
The stage takes its title from your role:
- Discovery, prioritisation and specs (product manager): product discovery and user research, framing the problem and the product risks, prioritisation frameworks used critically, PRDs and specs, roadmaps that communicate direction, working with engineering and design, and product sense. Milestone: notes from at least five user interviews, a problem statement, a prioritised list with a critique of your scoring, a one to two page spec and a now, next, later roadmap.
- Docs as code, structure and style (technical writer): docs as code, audience and task analysis, information architecture, the Diataxis framework, style guides and plain language, procedures and tutorials, Markdown and static site generators. Milestone: a small docs site in Git with a tested tutorial, a how-to guide and a reference page, labelled by Diataxis type.
- Developer experience and technical content (developer relations): developer experience, the developer journey, tutorials developers can finish, sample apps, talks and live demos, video and streams, and community foundations. Milestone: a journey map and time-to-first-success test for one product, a tested tutorial, a sample app and a recorded five to ten minute talk.
- Elicitation, requirements and process models (business analyst): core concepts, stakeholder analysis, elicitation, functional and non-functional requirements, user stories and acceptance criteria, BPMN process modelling, use cases and UML. Milestone: for one real small organisation, a stakeholder map, at least four interviews or observations, an as-is BPMN process, ten prioritised user stories with Given/When/Then criteria and a to-be process.
4. Working at a professional level (35 hours)
The skills that make a team rely on you:
- Metrics, experiments and stakeholders (PM): north star, input and guardrail metrics, A/B tests, stakeholder management, trade-offs and saying no, launches and strategy.
- API docs, review and maintenance (writer): API reference, OpenAPI descriptions, code samples that work, reviews with engineers, prose linting, release notes and measuring docs.
- Community, feedback and honest measurement (DevRel): community management and codes of conduct, feedback loops to the product team, events, content strategy and measuring impact without vanity metrics.
- Data, traceability and solution evaluation (BA): data analysis, data models and dictionaries, root cause and gap analysis, the business case, prioritising and tracing requirements, user acceptance testing and evaluating the solution after launch.
Milestone: checkable professional-level work in your role, written up so someone else can follow your reasoning.
5. Your portfolio (40 hours)
A portfolio as evidence, case study write-ups and learning in public, then role-specific samples: product teardowns, a discovery case study and a spec for a real product; a docs portfolio, open source docs contributions and a before-and-after rewrite; a focused body of public content, visible community work and a sample app; or a requirements package, a process improvement and a data analysis sample.
Milestone: a portfolio page with three strong samples, each with a short case study of your reasoning. Three pieces you can discuss for half an hour each beat twenty you cannot.
6. Breaking in (20 hours)
Internal transfers from engineering, support or QA, bridge roles, finding roles and reading titles, hiring exercises (cases, writing tests and content tasks), informational conversations and referrals, and avoiding scams and fee traps. Each role adds its own route: associate PM programmes described honestly, contract and freelance technical writing, community and ambassador programmes, or entry routes, domain knowledge and certifications for business analysts. Expect a longer search than for a junior engineering role, and plan for it.
Milestone: a written search plan with your route, target titles and companies, an exercise practised on a timer and applications or conversations under way.
7. Growing in the role (10 hours)
Your first 90 days, influence without authority, making your impact visible, staying technical, career paths (senior, lead or manager) and moving between roles. Business analysts get a topic on where BAs go next.
Milestone: a 90-day plan, an impact record template you use weekly, and a note on what the next level expects.
Projects
The roadmap links one or two FYP ideas per role: Product Discovery Case Study: From User Interviews to a Tested Prototype and A/B Test Analysis Report on a Public Experiment Dataset for PMs, Documentation Overhaul for an Open Source Project for writers, Developer Tutorial Series with a Sample App and Feedback Report for DevRel, and Approval Workflow Engine with Escalations for Small Offices for business analysts.
Stage picks include SVPG Articles, The Mom Test, Diataxis, Google Technical Writing Courses, DeveloperRelations.com, the BABOK Guide and Postman.
How it works on Sefism
The public page shows all seven stages, with the first two stages open to read. Everything on Sefism is free to learn from. Adding the roadmap to your dashboard uses credits: new members get starting credits and the first roadmap is free. Once added, every stage for your chosen role opens, with topic explanations, self-check questions, AI study prompts and picks, and you can track your progress. Following the roadmap also gives you its companion cheat sheet. If you are unsure which role fits you, send Tauseef a question or book a 1:1 session.
The companion cheat sheet
The Tech roles beyond coding cheat sheet comes in four editions, one per role, with 55 concepts each (69 in the business analyst edition). Use it to revise each stage and before a hiring exercise.
Related on Sefism
- How do I become a business analyst in tech?
- Can I get into tech without a computer science degree?
- How do I recover when I realise I chose the wrong career path?
- What Actually Happens Between Your Pull Request and Production, useful for the technical literacy stage.
FAQ
Do product managers or technical writers need to code? Not as their main output, but the roadmap spends 20 hours on technical literacy because all four roles read APIs, pull requests, JSON and SQL every week.
How long does it take to get into product management or technical writing? The roadmap is about 173 hours, roughly 24 weeks at 8 hours a week. Expect the job search to take longer than for a junior engineering role.
Is a certificate enough? No. None of these roles can be proven with a certificate alone. The roadmap asks for three strong public work samples with case studies. For business analysts it helps you decide whether an entry certification is worth it.
What is the most common way in? Internal moves from support, QA or engineering, combined with public work that proves the new skill.
Ready to start?
Opens on Sefism in a new tab.
Stuck on something specific?
Writing only gets you so far. If you want an answer to your situation rather than the general case, book a session and we will work through it together. Sessions are free for approved Sefism members, and a few slots open each week.
Follow along
New writing, resources and project ideas land here first.