I’ve worked a lot of jobs. Fifteen of them, in fact. This has been a tremendous benefit to my career as a software developer because it has taught me most of the soft skills I need, leaving only the actual coding to focus on. I’ve worked with lots of coworkers, lots of customers, lots of managers, and lots of companies. Because of this experience, I can tell, for example:

when a customer relationship is not worth the time to maintain because their end goal is to screw the company out of its service, not to pay for the service
when a coworker or manager is toxic and dragging a team down
the difference between a job interview initiated through networking (friendly, open-minded, with the interviewers genuinely trying to understand you) and a job interview initiated through the cold (in)efficiency of recruiters and job postings (nitpicky, austere, largely pointless unless you’re vastly overqualified for the position)
when and why punctuality and professionalism matter
when a customer feels they are being misled due to a lack of information
how to positively and negatively deliver both good and bad news

But there are also some enormous gaps in my knowledge of how work gets done, many of which have yet to be filled. And while I have sometimes found that Radial would have done better to have taken my advice in certain instances in the last twenty-one months of me working at the company (as hindsight has proven), both management and company culture have shown me just how much of the picture I was, and am, missing.

Job Flipping

Remember how I said I've worked fifteen jobs (sixteen if you count Uber and Lyft separately, seventeen if you count my two stints at Old Chicago separately)? Bearing in mind that I’m also twenty-seven years old, this may give you a picture of how frequently I’ve doubled-up on jobs, switched jobs, and hunted for jobs since I entered the workforce at sixteen. What’s up with that, you may ask?

I’ve sometimes wondered this myself. On reflection, my mindset of perpetual career motion stemmed from three key elements:

financial desperation. Most of the jobs I’ve held were retail, food service, or worst of all, gig economy jobs, none of which are known for paying well. It has been a simple matter to find a job that pays better than my current one for most of my career.
a lack of allegiance on both sides. I was laid off from my very first job as a Toys R Us cashier (and thank goodness). There are countless articles that talk about how it pays better to switch jobs than to stay at one. Both personal experience and the world around me was saying “Companies don’t care about you. Why should you care about them?”
there was nothing to stick around for. I’ve liked some coworkers and managers, to be sure, but I’ve always felt that if I only want to spend time with a person because I see them at work, the relationship can’t be that special. Furthermore, most jobs in retail and food service are dead-end jobs. Promotion to a position that pays significantly better is usually a slow, arduous, thankless process.

In short, the companies I’ve worked for were never really a part of how I defined myself. My performance at work, the work I do, has been a part of how I define myself for quite some time. But the company was not mine, and neither was my coworkers’ work. I could build myself a segmented locus of control within the company, figure out the system of mundane tasks entry-level jobs ask employees to do, and do them well. I have never been laid off since that Toys R Us job. Most of my managers from Silver Mine onward have been surprised to hear I was quitting because they took me for a satisfied, devoted worker. “Really? Why?” was usually their response to “I’m putting in my two weeks’ notice.”

They got the satisfied part wrong, that’s all.

A Promotion and Good Pay

Things started shifting a bit, again starting with Silver Mine. The key milestones were as follows:

A coworker at Silver Mine told me, “At first I was worried about how you’d do here. Then you started asking questions.” This flipped the switch in my mind that had failed to flip up until then: in school, you study before you take the test. In the workforce, no matter what job interviewers, recruiters, or anyone else tells you, you learn as you take the test.
One day, a different Silver Mine coworker and I were the only two people closing down the store. This coworker went to high school with me. We were both twenty at the time. That’s right, that entire Silver Mine branch had been entrusted to two guys who couldn’t legally drink yet. It struck me then that I am being entrusted with adult responsibilities, and adulting is not that hard if you stay out of your own way.
At Old Chicago, I was paid slightly better than Silver Mine when all was said and done because of how expensive car maintenance became as a delivery driver. Even so, $9 hour was… kind of low. I negotiated for a $1/hour raise and got it. In doing so I learned that, depending how I clocked in (for a dough cook shift, a pizza line shift, or a dish shift), I had been getting different pay rates, some of them below $9/hour. The raise corrected this.
At Simply Mac, I got my first promotion. I was working at the Fort Collins branch and got the job at the Greeley branch, even though an employee at the Greeley branch had also applied.
I ditched Simply Mac anyway because it paid better to be a part-time sales rep at T-Mobile than an assistant manager at Simply Mac

By continually swapping jobs, I was finally getting to positions that were more interesting to me (selling computers and phones is more my style than making food). I had started getting raises and promotions, which told me I was a valuable employee to the companies I worked at. And at T-Mobile, I finally stopped being financially desperate when I went full time and averaged $50,000-55,000/year in income (though much of it was held back until tax season because it was commission pay).

Ultimately, this meant that I worked at T-Mobile for three years, with a few side hustles in the form of a (very) brief position at 7/11, an internship at the Colorado Senate, Lyft and Uber driving, and a job as a JavaScript curriculum writer for Upscale Academy. But I couldn’t ditch T-Mobile. I didn’t have any serious allegiance to the company, and the career ladder required me to either have that allegiance or pretend that I did, so I knew I didn’t want to stay there forever. But it was a much harder task to find a better-paying job from that point.

The Obvious Wins of Radial

Radial paid about the same as T-Mobile when I started, ignoring the commission tax issue (it now pays a bit better—$65,000/year for full-time developers). I made the switch for the quality of life and career growth improvements that come with being a software developer rather than a sales associate, which turned out to be one of the best decisions I’ve ever made in my life. Here are a few obvious reasons why:

I used to go to work, stand around all day in a violently-pink room, and get yelled at by people who charged phone games to their bill and then wondered why the bill costs more now, albeit with a lot of coworkers I like (before that, the room was violently green). Now I go to work and type code into a computer, also with a lot of coworkers I like.
I used to get six weeks of PTO. I now get eight.
Healthcare is a company expense at Radial, not an expense withdrawn from your paycheck. U.S. healthcare still sucks, but it takes the sting off a little.
The snack room used to contain expired donuts brought there by schmucks trying to schmooze me into selling the latest (likely-to-explode) Android phone to everyone I spoke to. Radial has snacks chosen by the employees, for the employees.

I say those are the obvious reasons because those are the reasons you’d expect anyone coming from a retail job to prefer a software developer job, barring perhaps the coworkers they like and the snacks. Fortunately for me, Simply Mac, the Collegian, T-Mobile, and Radial have all had great people working at them. Coworkers I dislike are the exception, not the rule just about everywhere I work. Chalk it up to luck or an educated northern Colorado populace, but I don’t typically have a problem with my work teams.

A Less-Obvious, But More-Spectacular Win: Retrospectives

Radial changed my work week in some ways I did not expect, which I’m confident are uncommon in any job, in any industry. Take, for example, the oft-despised all-hands meeting with the manager. At many of my previous jobs, these meetings were miserable. The manager would talk extensively about whatever his manager told him, and how we’d be in trouble if we didn’t fall in line with what our manager’s manager said. This is a terrific strategy for making your employees fear for and hate their jobs. It’s a terrible strategy for making your employees feel wanted, appreciated, or cared for in any way. It’s also a terrible way to get any valuable insight from your employees, who are after all on the front lines interacting with the paying customers. When employees feel afraid or unsafe, they’re not going to come to you with their problems, and they’re also not going to be open with their opinions in meetings.

The fatal problem here is that companies that operate on fear are run by managers who don’t care about what their employees think in the first place. To them, a fear-inducing meeting kills two birds with one stone: it forces employees to behave a certain way (or appears to, briefly), and prevents them from disturbing the manager, which is more important to this sort of manager than understanding the company’s problems. This is precisely why communication lines fail at this sort of company. You can offer “open door” office hours, a phone line to call if you feel uncomfortable with team members, and every other “we’re open, talk to us!” line you want. But at the end of the day, running a company (or branch) through fear is guaranteed to render these communication lines useless. By never receiving feedback about what’s happening from your team, you can never help them solve the systemic problems crippling their performance.

Radial is completely different in this way. Retrospective meetings are held, not with the purpose of management declaring from on high that “things are gonna change around here,” but with the goal of tapping into the frustrations, worries, and problems that arose since the last meeting amongst the members of the team. Management will then create “action items” to be completed by either management or the best-qualified person to complete the item, which are written with the goal of resolving the issue.

I’m sure many companies have retrospectives. I’m sure many more companies have all-hands meetings. But this approach to company improvement and feedback blew me away when I started at Radial, and it continues to surprise me every time a serious problem arises within the company. Even our most introverted employees have voiced their concerns with their job at many retro meetings. This piece is crucial in that everyone is involved, but better still, they are regularly listened to and action is taken to help them work through their problem. Nothing says “this company cares about you” like listening to an employee’s personal problems with their job and helping them resolve those problems. On top of that, by laying out problems in the open, I’ve found that retros have solved interpersonal problems in the company that I had previously presumed were unsolvable in a work environment. At my previous jobs, these sorts of problems would have guaranteed a festering, bitter resentment amongst team members every day they came to work, which would only end when someone left the team. At Radial, our team is made stronger through our differences and our brokenness. I’m also 100% sure it results in a much happier, more productive team.

Radial’s retro meetings aren’t perfect. I’ve found that our more-extroverted, more-socially-comfortable team members are reliably engaged in the meetings, while others are not. I sometimes worry that this is inadvertently muting some voices that should really be heard. Action items also have a habit of taking a long time to complete. We chalk this up to the team being very, very busy (which is certainly true right now), but it can occasionally feel like the initial feedback was effectively ignored because the action item took so long to get done that it had zero impact on the problem it was meant to resolve.

Hack Time: What I Was Doing All Along

I frequently start working at a company and get bored after two or three months when I’ve not only grasped the work, but effectively mastered it. There’s no further improvement to be made to my workflow, beyond subtle alterations based on company or customer needs.

Radial is by no means boring. There are always new clients, new technical challenges, and new things to learn. But it endeavors to build into the schedule “hack time,” eight hours of a given forty-hour work week where I can theoretically work on any personal project I desire.

I say that I was doing this all along because that’s effectively been my strategy with my career for many years. I worked at Simply Mac, but wrote opinion columns for the Collegian on the side to pursue my passion for writing. I worked at T-Mobile, but started learning to code at Bloc on the side. I’ve used my self-declared hack time to create things and learn things and grow as a person. Of all of my personality traits, I think this is the one I’m proudest of: I’ll put myself through the discomfort of a strange and foreign experience in order to expand my skills and understanding. Good things usually come of this.

Being able to bill these hours to Radial is a huge benefit for me. I’ve been working on building Novum Opus almost since I started at Radial, and have found a surprising level of support and engagement from my team members in my (complicated, arduous, confusing) process of trying to build a system that can solve the $1.5 trillion problem of student loan debt.

The major drawback here is that “eight hours” of hack time is something of a lie, at least right now. Retro meetings and one-on-ones are hours worked, but not billable to clients, meaning thirty-two hours need to be billed and a couple hours on top of that are already allocated to meetings. If we work on policy documentation, that too must fit within that eight hour window.

None of this stops me, to be sure; I regularly work over forty hours, much to my managers’ amusement. But someday, eight hours of hack time genuinely, reliably being allocated within a forty-hour Radial work week would be a great thing to see.

A… Win? Stand Ups and Sprint Reporting

Stand ups are a staple of development teams practicing any flavor of Agile methodology. The concept is that team members report what they did yesterday, what they’re doing today, and what problems are blocking them. At Radial, we do this on Slack Monday, Wednesday, and Friday, and do it in person on Tuesday and Thursday. Some members of the team (our Director of Engineering and self-proclaimed work group leads, like me) also report on overall project status in terms of hours and progress toward that sprint’s goals. For the uninitiated, sprints are two-week segments of time in which we determine what we’re going to deliver for a client, why we’re delivering it, and do our best to reliably deliver those things.

Overall, stand ups are… fine. I think it’s helpful for me personally to think about what I’m going to be doing that day before I start thrashing randomly at problems. I rarely read other team member’s stand ups, though. One reason is that they’re often uninformative; one might read “Y: FFL, T: FFL, I/O: No,” which tells me… nothing, except that the employee is working on a project with the initials “FFL” that day. Another reason is that they’re largely irrelevant to me unless they’re from someone I’m working with directly.

Sprint reporting is similar. I put a decent amount of effort into my sprint reports, much to the appreciation of clients and management, from all I can glean. Yet I find myself unlikely to read other people’s sprint reports closely for more or less the same reasons I cited about stand ups. Many sprint reports I have read feel half-hearted, or else as though they were dreaded by the employee who wrote it, making them difficult to read.

In short, reporting is valuable if done well. It’s nearly useless if it’s not. I think the key issues are as follows:

The why of stand ups is not clear to everyone on the team, either because it’s never been conveyed or has been forgotten. On the one hand, there is an easily-resolved lack of clarity here: if management gets helpful stand ups, they can pitch in and solve problems proactively. if everyone knows this and values this, they’re far more likely to at least try and make their stand up informative. However, we’re so busy right now that there’s a valid argument to be made that the employee is not guaranteed help from management just because they put it in stand up. This is a dangerous precedent to set; I think it’s been a hugely positive thing amongst the development team to get help when they need it in the past, and it would be a bad thing to lose that.
The why of sprint reporting is, I feel, misunderstood (as the guy who kind of started the idea). I send sprint reports because I know I can clearly explain the goals of a sprint and our progress toward those goals by writing them down. I like to write. It gives structure to my thoughts where the spoken word never could. I do it a lot, so I’m pretty decent at it, if I do say so myself. If other developer leads find it more burdensome to write down a sprint progress update than to just talk about it in a meeting, and the client finds progress reports within a meeting context satisfactory, a sprint report is of less than no value. The concern I saw when I started sending them was that clients were often wondering where their money went, we would say “look in the sprint tracker,” and the notes there didn’t connect the dots for them. I don’t think all clients need a sprint report from all developer leads, but I do think that a service as complex as ongoing software development requires some form of consistent client communication to be effective. After all, I’d need to write out a breakdown of people’s phone bills at T-Mobile for them to understand it, and that’s a far simpler concept to grasp than the concept of a software development sprint. If the client can translate project stories into colloquial terminology themselves, they don’t need a developer lead to do the translating; otherwise, that’s one of the main purposes of a developer lead, as far as I can tell.
We’re very busy right now as a company. It’s easy to use that as a scapegoat for a lot of problems we’re encountering (not least because they were also problems when we were a lot less busy), but it surely plays some role in the challenge of making project reporting helpful.

Ideas Made Real

I can’t take credit for most of the things that make Radial what it is. The general structure of the company existed before I showed up. If I were ever to leave, it would continue functioning without me. While I’ve been at Radial, most of its operation has gone on without any input from me.

But coming from the world of entry-level jobs at enormous corporations, it has nevertheless been a tremendous honor and privilege to have contributed to the ideas and strategies that have helped scale Radial, which I feel is the story of Radial’s 2019. Here are a few things I’m particularly proud of, both because I contributed to them and because they were implemented successfully:

When I started, I pushed pretty aggressively to have a salesperson on the team. I thought that could maybe be me, which turned out to be a poor scoping of how to solve Radial’s problems. Nevertheless, we now have a salesperson, a sales funnel, and more sales than we know what to do with, the opposite of our situation in 2018, because we as a company have taken sales more seriously since January. I can’t take the credit for the proper implementation of this idea, but I certainly feel I pushed our developer-focused team to recognize we need sales, and also need to appreciate getting them.
As mentioned above, I think I can take quite a bit of credit for an improvement in overall client communication, both by encouraging developer leads to report on sprint progress to our clients at the end of each week and by setting a good precedent for project reporting expectations.
I contributed pretty significantly to our team effort to redefine our company values.
I understand how important it is for us to mess up, so we can know how to bounce back from it, learn from it, and get better. I also know that Radial figured some things about itself right before I started working there. But I also feel like the reasons cited above, and the positivity I attempt to bring to work with me whenever I can, have led us to several victories where our previous strategies would have failed us.

If I had all these same ideas at any other company I’ve worked for, they would have been at best completely ignored, at worst scoffed at because I didn’t have the job title to be discussing such things regardless of the quality of the idea.

Simultaneously, the way I work has fallen on its face pretty badly at Radial, more than once.

At a retail store, if you’re overworked, it’s a short-term problem. Eventually the shift ends or a team member grabs the next customer, and now it’s no longer your problem. At Radial, projects are scoped to developer leads to a certain degree, but if you fail to reach out, you start to drown under the workload no matter how good a work ethic you have. One project I was leading had to be handed off because I failed, horribly, to pull in additional support when I sorely needed it.
Because of my habit of leaving jobs early, I often find it easiest to just avoid someone who I’m struggling to see eye-to-eye with. After all, in most cases, I’ll be gone soon. Radial is not that way and is not going to be that way. If anything, I think this is the very worst time to ever leave Radial, because this company is going places, and I want to go to those places with it. This means that I’ve had to learn to face some of my nastier habits, such as discarding the opinions of others (and sometimes that person entirely) when I’ve made a snap judgment that they don’t deserve my respect.

In fairness on that last one, I think there are also a couple of times when Radial did not follow the path I thought we should follow, and we have been worse off for it. I’ve expressed my concern about some clients and personnel and found my opinion fell on deaf ears, only for it to come back to bite us because my instinct was right to begin with. Going forward, I hope to do a better job of articulating why I have reservations about an idea and where that reservation comes from, so it can be considered more critically by myself and others. I also hope to do a better job of reserving judgement so “my opinion being right” never becomes a self-fulfilling prophecy, which is to say that the initial distaste toward an idea or business strategy shouldn’t sour the idea before it was really given a chance.

Always Halfway Out the Door

I’ve gotten into a habit of leaving companies quickly. There’s always at least one “reason” to leave that I can come up with for any place that I work: this company will pay me better, this company has better benefits, I’m sick of this toxic environment, I’m sick of these customers, I’m sick of the idea of this job, the list goes on.

What I’m discovering is that I’ve built “leave as quickly as possible” into an instinctual habit because it has served me well in the past. My experience at Radial has taught me that I can remain this way, but I shouldn’t. I can let where I work be part of how I define myself, I can unironically say that my team at work is like a family to me, and I can stop for a moment and enjoy how far I’ve come since I learned what Ruby hashes were in 2016. “Settling” for something is often a sign of stability, not a sign that you’ve given up or stopped trying, and now might be a good time to dig in and explore my career more deeply rather than more broadly.

Radial comes with its flaws, like any company. But the empathy the team shows each other and the value the company places on its employees, their ideas, and their feelings makes it far greater than its problems, and it’s that above all else that has made it a second home for me.

This post was sponsored by Radial Development Group, but the opinions are my own.

Post number 61.

Blog