DaedTech

Stories about Software

By

Escaping Sucker Culture

A lot was made of my recent and popular post, The Beggar CEO and Sucker Culture. Given the traffic that it generated, discussions took place ranging from the merits of developers unionizing to startup versus established corporate cultures. Perhaps the most common theme, however, was what my call to action was and the actual mechanics of escaping sucker culture.

In my comments and in social media, people offered messages along the lines of, “what do I do to escape when I’m trapped,” and “I drew a line in the sand and got fired, so don’t rock the boat.” To be clear on what I was advocating in my post, I wanted people to stop accepting that they owed companies (and people like Victoria) free hours and to stop feeling guilty about not wanting to oblige. This is a far cry from a call to action of, “tell your boss you’ll never work a minute over 40 hours again and if she doesn’t like it, you quit.” I was calling for a subtle shift in attitude and not any specific action.

But this does beg the fair question of “what comes next?” Resolving not to feel like you owe your spare time to the company is all well and good. But it doesn’t get you home to your loved ones – it just gets you to feel resentful while you continue working the same schedule. So in this post, I’ll offer up some ideas for how to reclaim your hours and stop being forced to give handouts to companies.

DevOpportunityCost

I want to be clear about something, though.  I’m offering ideas for things you might try and not a step-by-step how-to.  Office political situations are extremely nuanced, and, if you like the thoughts I’m offering, you’ll need to figure out how to tailor them to your own situation.

Read More

By

Getting That New Tool Past The Gate Keeper

Editorial Note: this post was originally written for the SmartBear blog.  You can read the original here, at their site.  Check out the rest of the content while you’re there.

Let me tell you a tale, and stop me if it sounds familiar.  Well, I suppose the medium of blogging will prevent you from actually stopping me, but you get the idea.

You’re part of a software development group, and you’re surrounded by techies like yourself – people that get excited about new ideas, approaches, tools, frameworks, and languages.  But then there’s the guy on your team with the seniority.  Let’s call him Crusty.

Crusty is not your boss. He’s probably the team’s architect or even just a senior developer who is somehow, implicitly, more senior than the other developers.  Most significantly, he’s who management looks to for advice about whether to adopt things – the very things about which you and your teammates tend to get excited.

His answer is usually “no.”

Lifer

Management loves a guy like Crusty because he’s reassuring to them.  If you’re a dev team manager, the developers are constantly clamoring for new things, and you begin to wonder, “Is all of this really necessary?”  A good manager trusts her people to make recommendations, so she’ll tend to go along with it and hope that the spending is not wasteful.  But if there is a go-to guy on her team saying, “nah, we don’t need that,” she’s going to be grateful.  She has someone to reign in the spending, and she’s provided with the (potentially false) sense of security that, when something is actually needed, this guy will speak up.

This leaves you facing a conundrum if you’re part of such a group and want to propose a tool for adoption.  I talked previously about how to sell management on a tool, but Crusty effectively acts as a gatekeeper between you and making your case to management.  If you approach your manager directly, she might say something like, “Run it by Crusty first and get his buy-in.”

So, how do you get past this gatekeeper?  You need to understand his motivation and act accordingly.

Read More

By

The Beggar CEO and Sucker Culture

The other day, I was doing something on LinkedIn, when I noticed a post title that somehow made its way into my feed: “Why Don’t My Employees Work Harder?”  I clicked through out of curiosity and found that this was a corporate Dear Abby sort of thing.  A CEO identifying herself as “Victoria” submitted the following as a question to Liz Ryan, who serves as Abby.

Dear Liz,

I know that leadership is all about trust and I do trust my employees, but I wish they would show a little more effort. They come in on time and they get their work done and that’s it.

I leave my office around 6:15 p.m. most nights and I don’t think that’s an especially long workday. But the parking lot is nearly empty every night when I leave. Why am I always one of the last half-dozen people out the door?

When I started this company six years ago there was a lot more team spirit. Now I have to come up with incentives to get people to put in extra effort.

I haven’t threatened anyone or threatened to cut the bottom ten percent of the team or any of that but I did tell my managers that I want them to incorporate not only output but also effort into their performance review rankings.

I want to reward the people who work the hardest here and make it clear that anyone who wants a ‘dial-it-in’ type job is not a good fit. I don’t think a growing, $10M company should be a place where people work from nine to five and then go home. What do you advise?

Thanks,

Victoria

Clipboard

I tweeted my gut reaction to this off the cuff, and it got a lot of traction for a random tweet on a holiday morning.

I then read through Liz’s response, which was patient, well-reasoned, and it brought up something called “weenie management,” so that alone is sort of oddly awesome. It also pretty resoundingly dressed Victoria down, which, I think was warranted.  And yet, in spite of expressing my disgust on twitter and seeing a somewhat satisfactory response to Victoria, I still felt sort of bleak and depressed about the whole thing.  I stewed on it further and realized what my response would have been, had I been Liz. Read More

By

Agile for Introverts: Re-Imagined Programmer Collaboration

As I mentioned in a recent post, I’ve been listening to Susan Cain’s, “Quiet: The Power of Introverts in a World that Can’t Stop Talking.” I also mentioned that I’d be saying more on the topic, and here comes some more.  Today it’s going to be the idea of Agile for introverts.

In recent weeks, I’ve spent some time running a bootcamp of sorts that covered, among other things, XP and Scrum principles. Personally, I find that I light up when talking about clean coding practices and that I’m a bit more tepid when it comes to explaining process particulars. Reflecting one evening, it struck me that a lot of the practices involved in Scrum ceremonies and some of the XP practices aim to draw people “out of their shells.” In other words, a lot of agile is the Extrovert Ideal brought to programming.

This made me wonder what some Scrum ceremonies and/or XP practices might look like if they were introvert-friendly. That is, how could one accomplish the goals of these activities in ways that didn’t assume “let’s all get together and collaborate always!” was the right way to think.

What is introvert-friendly?

Before I can offer thoughts on how to make something introvert-friendly, I want to define what I mean by that. I feel it’s important to do so because the definition most people would assign by default is “things that don’t require interaction with others,” and that’s not right.

I’m going to go out in a limb here a bit and assume that I’m a good representative of the introvert population as described by Cain. I don’t feel that this is too much of a reach, since I got a 20 out of 20 on the informal “are you an introvert” quiz. So, I’ll explain my own psyche and trust that you find it reasonably representative of how you feel if you are also an introvert.

I don’t seek to minimize social interaction, per se, but I do shy away from unpredictable situations with a large amount of stimulus.  I also have an intense preference for a sort of social order that is predicated upon minimized conflict and a world in which information and opinions aren’t generally shared unless solicited.  You can actually read back through my blog posts and see a lot of this described before I’d ever heard of Susan Cain’s book.

There are probably more, but these certainly capture some of the themes at play here.  And from this basis, I propose the following concepts as introvert-friendly.

  • Differences of opinion are resolved by folks having time to process different viewpoints and build a case rather than by extemporaneous argument/debate.
  • Meetings and gatherings are limited in size.
  • In professional situations, it’s better to remain silent unless you have something high value to say, especially in larger groups.
  • Interpersonal interaction is primarily for camaraderie and logistical resolution (e.g. knowledge transfer or merging code), rather than important work.
  • The most productive work happens in a state of flow when you can tune the world out and concentrate.
  • It’s worth letting a group make a sub-optimal choice to preserve social harmony.
  • It’s good to be able to opt out of groups that frequently make sub-optimal choices.

Notice that none of this is, “I want to be home, alone, always, with no interaction.”  That’s not introversion — that’s being a recluse.  Rather, this is “I prefer orderly interactions, a cap on external stimulus, and time and space to form my ideas.”

Read More

By

Your Coworker’s Bad Code: Having The Hard Conversation

Editorial Note: This post was originally written for the SmartBear blog.  You can check out the original here, on their site.  If you’ve never had the chance, take a look at their blog in general.  A lot of good authors over there.

Last time, I talked about how to prepare for a tough conversation with a coworker about having bad code.  This included understanding what not to say and creating a game plan of specific shortcomings to address and concrete outcomes you want from the conversation.  This time, I’m going to talk about how to actually engage with your teammate, who I’m calling “Bob.”

Engage

Having built your case ahead of time, it’s time to go have a chat with Bob. You’re calm, you’re rational, you have a legitimate argument, and you’re all set for a constructive dialog…but the lead in for the conversation threatens to be awkward. What I’d suggest doing to put the conversation in more natural terms is to ask for his help. “Hey Bob, I’m chasing a defect through the code and it led me to this method of yours. It’s a little hard to follow at first glance, so I was hoping maybe we could trace through it together?” Now you’re not coming over to preach to Bob about the evils of his code but rather to ask him to help you solve a problem.

Once you’re looking together at a screen and starting to dig in, one of the most effective ways I’ve found to surface code problems is through the Socratic Method. Instead of telling Bob that the method is too long, ask a series of questions. “Wow, good thing you’re here—this is a pretty long method with a lot going on. How long do you think it would take the average team member to understand it?” “Huh, wow, three or four hours seems like a pretty long time to spend trying to understand a method, don’t you think?” “What if it were smaller?”

Socrates0001

Making proclamations of fact or strongly stating opinions tends to put people in a defensive posture. Asking questions, even leading ones, doesn’t get people’s hackles up as much. They tend to join you in problem-solving mode rather than argue against you in debate mode. Still, asking questions this way may not lead to the desired outcome, which is why you’ve done your homework. Switch gears from the questions to statements of your experience and how you feel. These are inarguable. Read More