We've all been there, part of a team where one person ended up doing most of the work. Was it you? I know it's been me. Perhaps I was troubled by the others' procrastination and so I just forged ahead, or that I wanted it done a particular way, or that I was a know-it-all or something. In the end, it might have been some or all of those things, but from the lofty position of having been working for decades and decades, I can see that I was a “citizen developer,” someone who does something outside of their assigned role or who builds something that wasn't part of the brief and made things a little better because of it.
Some folks prefer to stay in their lane and some folks end up as citizen developers, either unwittingly or deliberately doing things that aren't specifically part of their job. Sometimes, everyone benefits, sometimes it's a pathway to a different career, and sometimes, it's annoying and gets in everyone's way.
I got laid off from my day job about a year ago and I've done a lot of thinking about the good, the bad, and the ugly at that place. One of the fellows I worked with was a citizen developer, although he didn't deal with code. He knew everyone, knew what they did and where their expertise lay, knew how to get things done, and he was astonishingly productive. He was always volunteering to be on a team, often mentoring some new hire, and just social enough to make healthy connections among team members when it was needed. Was he a great tech writer? No. His work was done and done on time, but was it great? No. Was he a great project manager? You betcha. He was open to new ideas and people, ready to try things just to see what happened, always the first to stand up to take blame and fast to give credit, and willing to work to see a project through and do whatever was necessary to make it successful. He was a non-programming type of citizen developer, making sure that things ran smoothly, making life easier for the actual developers and for the rest of us. Sure, there was always someone thinking he'd overstepped, but for most of us on the team, he sure made things clear and simple.
I really appreciated that someone else had connected the dots. I could just take my little stack of words and go off and tidy them up. This guy let me know what the schedule was, if any hiccups had encroached, whether I needed to increase my work boundaries, or whether the project had slipped and wasn't a priority. I didn't have to go to endless meetings because he did. And I didn't have to seek information about my projects because he was so good at letting everyone know what had come from the endless meetings he attended. Oh, and he was great at running meetings. He'd have all the relevant players on the call (we were largely remote and international), most meetings were single-subject so we'd get in and out, and he made sure all of the attendees knew what was being discussed. I can't remember a single one of his meetings ever running over the allotted time.
This may not sound like a citizen developer at first glance, but this guy's title was Technical Writer. He wrote the things he was supposed to write, but he stepped into the project manager's role so effortlessly and efficiently, it was hard to remember that someone else was probably supposed to be doing these things.
Not everyone intrudes outside of their purview so welcomely. There was also a person who'd been an engineer working on UIs several jobs prior. He was now a tech writer, but rather than writing and project managing, he spent his time going down nearly irrelevant rabbit holes - reacting to things. Oh, some of them were UI-related, because that was what he thought he was expert in (there were paid experts in UI stuff, but he always thought he knew more/better even though he wasn't hired to do anything with UI stuff), but some were about word usage (usually in someone else's documents), how to run a meeting (complaining about rabbit holes in meetings when he had initiated 100% of them), and worst, encouraging others down rabbit holes defending their own turf against him. He didn't go to meetings about his own writing projects, turned in very little actual writing, and what he turned in was twisty-turny non-linear and not publishable. He had no idea who his audience was nor what their needs were because the only voice he listened to was his own. He wasn't an unpleasant person, but he sure worked hard to avoid doing his job, the sort of citizen developer that gives the rest a bad name because he's not accomplishing anything useful. In his effort to be thorough, he often lost track of what was needed and what his job was about: technical advice for people using the product. To him, it was more important to document comma placement than it was to describe what functionality could be found in the product. Don't get me wrong: I'm all about comma placement - that was my job as the company's editor - but someone needs to tell the users what the product does!
These are two extremes. One citizen developer makes projects flow more smoothly and makes a better work environment, and the other interferes with progress and the people whose expertise is spelled out in their title because they're reacting in the moment and missing the bigger picture. It's a hard spot for employers - when is overstepping boundaries a problem and when does it improve the work situation for the team?
A good citizen developer is confident enough to try their hand at things and to recognize where the lines are drawn, and the bad citizen developer is avoiding the task at hand and getting in everyone's way, assuming expertise that no one wants them to share. As an expert procrastinator myself, I recognize the symptom - other stuff seems so much more interesting than the task at hand. Heck, I wrote this editorial when I was supposed to be editing something tedious. (I call it “productive procrastination” because I'm doing something useful instead of what I'm supposed to be doing. I write a lot of arrangements for my musical trio when I'm supposed to be editing this magazine, for instance.)
Companies can benefit from citizen developers. Years ago, I worked for a manufacturing company that encouraged its skilled line workers to take engineering classes, and they actively promoted people into engineering from the line without a degree. Another company, where I was a librarian, let me edit their lab reports after hours. That's where my current career came from. I was good at it and I got better while I was there.
Citizen developers largely add value to projects. You're going to get some bad eggs and some people who just can't bear the idea of someone else doing something differently from how they might have. And the dynamic within the team can be tricky, even if the citizen developer is really good at what they do.
Recognize whether you're the sort of person who steps in when it's needed or if the team is better off letting - or getting - someone else to do it. Most importantly, if you're a citizen developer, do you know where the line is between what you know and what you don't know? And if you're working with a citizen developer, can you appreciate what they offer?
