Download to read offline
Uploaded byBeth Aitman
Models for personal growth: career progression for tech writers
The document provides guidance for tech writers on personal growth and career progression through skills-based and impact-based growth approaches. It emphasizes the importance of creating a personal development plan by assessing core skills, identifying areas for improvement, and focusing on tangible goals. Additionally, it discusses the significance of addressing meaningful problems and making a measurable impact within one's organization.
Models for personal growth: career progression for tech writers
- 1. Models for personalgrowth: career progression for tech writers Beth Aitman | @baitman lead tech writer at @improbableio
- 2. The problem: how doI progress? @baitman intro - skills - impact - end
- 3. skills-based growth impact-based growth @baitman intro- skills - impact - end
- 4. skills-based growth impact-based growth @baitman intro- skills - impact - end
- 5. Skills-based growth @baitman - Progressionmeans: - Improving existing skills - Learning new ones - Identify the core and marginal skills intro - skills - impact - end
- 6.
- 7.
- 8. Creating a personaldevelopment plan @baitman 1. Take the core skills, and others you think are relevant to you 2. Rate your existing skill level, out of ten 3. Choose which ones you care about improving 4. Find some concrete things to do intro - skills - impact - end
- 9. Concrete stuff todo @baitman - Over the next <time period> I will have <done/improved at/tried/learned> - Specific, Measurable, Actionable, Realistic, Time-bound intro - skills - impact - end
- 10. Mastery @baitman - Your worktakes less review - You’re quicker - You find other/more interesting ways to do something - People come to you for advice - Someone you consider a master assesses you intro - skills - impact - end
- 11. Mastery @baitman - Your worktakes less review - You’re quicker - You find other/more interesting ways to do something - People come to you for advice - Someone you consider a master assesses you intro - skills - impact - end
- 12. The skills-based model @baitman intro- skills - impact - end
- 13. Impact-based growth @baitman - Lookat your career progression based on results - Example levels: - Helping a small number of people - Helping a larger number of people - Enabling colleagues to help lots of people intro - skills - impact - end
- 14. Planning using impact-basedgrowth @baitman - “What problems are you interested in solving?” - “Where do you think you can make a difference?” intro - skills - impact - end
- 15. Planning using impact-basedgrowth @baitman - “What problems are you interested in solving?” - “Where do you think you can make a difference?” intro - skills - impact - end
- 16. How to chooseproblems @baitman 1. What problems do you know about? 2. Do you know how to solve (or how to approach solving)? 3. Do you have the skills? Can you learn them? 4. Are you allowed to? 5. What’s the impact? intro - skills - impact - end
- 17. How to chooseproblems @baitman 1. What problems do you know about? 2. Do you know how to solve (or how to approach solving)? 3. Do you have the skills? Can you learn them? 4. Are you allowed to? 5. What’s the impact? intro - skills - impact - end
- 18. Having more impact @baitman -Helping colleagues - Working on big user problems (lots of user base, core workflows, really bad right now) - Working across multiple teams or systems - Spotting problems and improving processes - Contributing to better decision-making or design - Helping the org’s future (eg hiring) intro - skills - impact - end
- 19. Actually making progress @baitman -Make a plan (from skills or impact or both) - Review the plan regularly - Take opportunities! intro - skills - impact - end
- 20.
Editor's Notes
- #2 Morning everyone! <intro> So I wanted to give this talk because of a problem I’ve hit a lot of times since I started out as a graduate technical writer. Very often I’ve been at a point where I feel I want to get better at what I do, I want to grow, and I’ve found it really hard to work out how to do that. I don’t think I’m alone, either - I’ve had plenty of conversations with other technical writers who also find it hard to work out.
- #3 For technical writers, there often isn’t a path laid out going “upwards” through a traditional hierarchy, so it’s not clear where it is that we can go. There’s the general ‘career path’ option to become a manager. That as your only path is a reductive idea. It works really well for some people, but for others - it may not be what you want to do, and it also may not be a practical option for a tech writer, because there tend to be not many of us. Another option: lots of tech writers end up moving sideways out of the role, into doing something else. And that can make tons of sense, but we shouldn’t have to do that just because there’s no other option. So I want to try to explore the options by talking about two ways of conceptualising growth/progression: one way based on looking at your skills, the other way based on looking at our impact. They’re from my experience, of managers talking to me about my growth, in career discussions where we’ve been working out where I’m going.
- #4 These are the two. Skills-based growth is, surprise surprise, thinking about your growth in terms of your skills. That includes the skills you already have, and how you improve on those, and the skills you gain or might want to learn. My experience with skills-based growth is that first company I worked at had some problems with giving people enough career progression, and rolled out a skills-based progression to try to give people that.
- #5 Impact-based growth is pretty different. When you’re looking at growth this way, you’re looking at how you make a difference: what problems did you solve, what difference did you make? In this model, you grow when you solve bigger problems, or when the outcomes of your work have a more significant effect. This is a model I was introduced to where I work now, at Improbable, and I’ve used a lot to think about how I’m growing there. For both of these I’ll talk a bit more about what each of them means; how to use them to assess where you are, and to work out how to develop next; and some of the advantages and disadvantages of both models. The goal is to give you some frameworks to think about your career growth: how you’ve grown so far, and how you could grow in the future. So to start with I’m going to dive into skills-based growth.
- #6 When you’re looking at your growth in terms of skills, there are basically two options for growth. The first is: improve the skills you have already. For someone who’s just started in the role, this would mean learning the basics and then improving on them; for someone who has those basics, this is trying to grow towards mastery. The second is: pick up new skills - and obviously, they should be skills that are relevant to your job. We always used to use glass-blowing as an example of something you couldn’t put on your personal development plan. And in general, you’d expect a bit of a correlation: the core skills are the ones you’re improving. Skills you’re learning, especially if you’re more experienced are more likely to be considered marginal skills. This is a bit hard to consider in the abstract. In order to be able to think about how to grow in this model, you need to identify what the relevant skills are.
- #7 Here’s one example of how to do that: a skills map. There’s a lot to take in here, so let me talk you through it. Core skills. Directions. Specialist isn’t really a direction but lots of them. UX has own map. Directions can mean you’re intending to change roles - eg someone who became a product marketing specialist “exited top right” - but not necessarily. This was created by my first company to try to deal with the problem I mentioned earlier, to try to help people work out how to progress. Tool to facilitate discussion - Where have you gone so far? Which direction interests you?
- #8 This is very specific to that company. For example, Confluence admin. If you created a map for how you see your job, it might look quite different. You might disagree on the core skills - for me, I’d bring reviewing in from the specialist direction, and remove estimating from the core. But this doesn’t have to be perfect. It’s just a tool.
- #9 How we used this tool was to create a Personal Development Plan. Pick the core skills and the others you think you have/care about. Rate your existing skill level. Pick a number out of ten - it’s just a handwavy guess, to give you a rough idea. Then choose of those which you thought it was actually important to improve on. Some you might decide you’re fine at the level you’re at, eg my reviewing skills are serviceable and making them better won’t change much. If you’re interested in exploring a different role, you can pick some of those skills and use that as an opportunity to try it out. So at the end, you’ve got a list of areas you want to work on. The next step is working out what to do.
- #10 This is a problem of the skills map: it’s not enough to identify the skills you want to improve in - tend to need an actual action plan if you want to get better. That can be really hard. For example - I think I’m a decent writer, my documentation is reasonably clear and effective. I could say, actually, the most important way for me to grow is to absolutely master writing. Fine. How do I actually do that? There’s not really any guidance at all. What we did was identify particular activities and actions you’ll take to improve those skills. There were a bunch of examples to spark ideas: I will have done a thing, tried a thing, learned a thing. In practical time frame. Doesn’t have to be the right ones, just has to be something. SMART goals are helpful.
- #11 One of the limitations I’ve found of skills-based impact is it tends to work better for less experienced people. Because when you’re a bit more experienced, it can be harder to identify your level, and harder to work out how to improve. What does it even mean to master a skill? I’ve seen a few ideas of how to identify that. Your work takes less review. You’re quicker than other people, or quicker than you were. You find other solutions. People come to you for advice. Someone who you consider to have mastered the thing can assess you. But how to actually improve on these? It totally depends on the skill. Often can’t say much more than “have a mentor to guide you”.
- #12 Ironically, this leads to the main problem I had with the skills-based approach. I found this encouraged me to focus on marginal skills. When I was going through this process, I wasn’t really sure how to improve at those core skills, apart from ‘keep practising and getting feedback’. Not much of a growth plan. So it was much easier to pick new skills to learn. I got to learn a bunch of new stuff, but it didn’t necessarily feel like I was deeply enhancing what I did. For example, for me: I put learning to run user research sessions on my PDP. I would have attended them anyway, so the the difference between running a user research session and just attending wasn’t huge. Or web development: it broadened my experience, and it was really fun. I was really glad I got the opportunity to spend time on it, but it’s not really clear that it made me better at my job.
- #13 So this model of growth has its uses. Can give you ideas about direction - it’s good for sparking ideas. If you don’t have a clear idea of what options might be available to you when thinking about expanding your role, this can help. It’s great if you’re early on and still need to develop core skills. Can also be handy if you’re moving in a new direction. But there are some situations where it’s not very helpful. If you’re confident in your skills, you may not feel that focusing on improving them will make much of a difference to you. And if you want to stay working on the same core area, thinking about new directions may not be of interest. So let’s move on to impact based growth.
- #14 To recap, in this model of growth, you grow when you contribute more. You progress in your career when your work and your achievements have more impact. What does impact actually mean? Essentially: what difference do you make? And roughly what scale is that on? So for example: writing a page that helps a few users. Fixing something that a lot of people use. Or teaching your colleagues to improve docs, so that more people contribute. Doesn’t have to be scientific, exactly weighing it up. It’s more about being aware of the magnitude. By the way, this is where management fits in - rather than thinking about it as moving up the hierarchy - the reason that becoming a manager is career growth is because you have an impact by enabling other people.
- #15 So this model is something I came across in my current job. Had a six-monthly review and was asked, how do you want to grow in the next six months? (at this point I was the only tech writer in the org, there was no path laid out for me) I talked to one of the engineering managers who I often go to for advice, and he pointed out that one way of thinking about that question is to make it less personal. “How do you want to grow?” is essentially asking you “What do you want?”, which can be a very hard question to answer. Instead he suggested different questions: “What problems are you interested in solving?” “Where do you think you can make a difference?”
- #16 I personally find this really helpful. I don’t know where I want my career to go, but I find it much easier to think about what problems I care about solving and think I can help with. Sometimes those problems aren’t strictly tech writing problems - for example, I notice some ways in which our internal communications aren’t great, and think I can see a way to fix it. I also like that it encourages you to think about how your work makes a difference, and which bits of it make a difference and which don’t actually have that much impact. My example, when I was really stretched and there was a ton to do, was fixing typos in the docs site. It wasn’t unimportant, but when I looked at impact, that clearly wasn’t the best place I could spend my limited time.
- #17 Picking problems can be tricky. It relies on a bunch of things. Firstly, identifying the problems. Sometimes you have some obvious things in your head - you know about something which causes a lot of pain for customers, or something that’s been frustrating you for ages. If you don’t know what the biggest problems are, especially for users, stepping back and doing some research is a great way to get material for this. Next, do you know how to do it? You don’t necessarily have to know how to do the whole thing, just how to begin. For example - our ‘onboarding workflow’, ie how we get users started on our tech, is a total mess right now. It’s a big deal, getting it right will make a big difference to our users and to the company, and it’s on my list. I don’t know how to get it right. But I do have some ideas that can be a good starting point, and I know what research we’d need to do to validate those ideas.
- #18 Next - even if you know roughly how to approach it, that doesn’t mean you can do it. Another personal example - a year ago, when I was the only writer, one of my goals was to grow a tech writing community at my company. I’ve never been a leader in that way before - but I could learn. And in some areas the easiest way is to learn through doing. This relates back to the skills map. If you’re interested in the problems of another role, you can choose to start solving them. You don’t have to be certain you want to be a project manager to do more things that are like that job, and to grow through doing so. Rather than thinking about roles, thinking about the problems you enjoy solving can be a good way to think about this obliquely. This thing can be a bit tricky. You might see a really big problem that you know you could help with - but for some reason, you feel you’re not allowed to. Maybe because someone else owns it, and it’d be treading on their toes. In this case, it depends on how bold you’re willing to be. Sometimes you can just go for it. Sometimes if you ask permission at the start people might say no. Try things like doing the first steps and then showing your work; or writing a proposal for a minimal starting point. This can be really intimidating, but it sometimes also means you discover you’re “allowed” to do more than you think. And of course, identify what the impact is.
- #19 Finding ways to have more impact than you are now can be hard, so here are some concrete examples of finding ways to operate at a higher level. Some of these will mean you’re doing work similar to that of a manager, or of someone in a different role. Talk through the examples. What that might look like in practise - I want to show you some examples of our levelling guidelines for software engineers - what being more senior and growing looks like for them. All of these are about being a software engineer, but the parallels with other roles are pretty easy to make.
- #20 And before I finish up, I want to talk about the practicalities of growth, too. It’s all well and good to spend a bunch of time thinking about where you are and how you’d like to grow. But in general that doesn’t tend to lead to much unless you actually have a plan, and a way of sticking to it. I’ve often had very helpful managers who helped me look at the areas I wanted to grow in. They helped me come up with concrete things to do in order to make progress - SMART goals (look it up) that would be clear signs of achievement and growth. They’d regularly bring up what I said I was planning to do, and if a few months went by and I hadn’t made any progress, we’d talk about why - whether I actually really cared about that goal any more, and if I did, why I wasn’t making time for it. The other thing that became really clear was: so it’s helpful to have an idea of where you want to go. But most growth really comes from opportunities. Keeping your eye out for new things you’re interested in, new projects you can help with, and being willing to say yes to things and jump in when there’s a chance. It helps to have these models to understand where you want to go. But you have to keep an eye out for the chances to make it happen, too.