And you are here why?

Let’s set the scene. You’re at work, and there’s one of  those things happening, where Alice (or Bob) have come to a decision that is  self-evidently dumb  as far as you’re concerned. You  know you’re right, and you  know  they’re   wrong. Or, it could be a bigger thing. This could be a design meeting, and the rest of the team is going down a road that you just don’t agree with. Or even worse, it could be the tech-lead (or product-manager, or your boss) handing down a decision from on-how to do this  clearly  stupid thing. Soooo, what do you do? • “ F**k-it, it’s not my problem ”? If so, you’re probably seriously burned out, in which case you should move on. Or, you might be in a “collecting a paycheck” kinda place, in which case the rest of this post really isn’t for you. • “ Yup, let’s get it  on ! ” Ok, maybe not quite this phrasing, but it does bring up the question of how forcefully you should argue, and/or get into the f...

It’s (not so?) surprising how contentious the above statement can get. The responses to it exists on a spectrum, with one end consisting of Libertarian-types who hate the very concept of Management, and the other end consisting of Dictatorial ass-hats who are convinced that things would be just fine  if only people did exactly what they were supposed to in the project plan!!! The thing though, is that there  is  an element of truth in the above statement, but, as with all things, semantics matter. Let’s break “ Software ” into two categories • Engineering : The process of finding the appropriate solution to the problem at hand. Frequently, this also involves figuring out what the problem is in the first place! • Coding : Implementing the solution that was identified in the  Engineering step above. When broken out like this,  Coding  is “hard” in the sense that there is skill involved. It may take years —  or 10,000 hours  — to become great at th...

The — truly — sad part is that I’ve seen pretty much all of these applied at some point or the other. It is actually particularly prevalent in small/lean/agile/rapidly-growing companies who bring in “professional management” to “take them to the next level” (scare quotes intentional). You see — in enterprises the above “professionals” tend to act as checks&balances on each other, cancelling out their own worst impulses.  However , when they are provided the unfettered power of a small company, well, all bets are off. Oh, they  might do good, but more likely, you end up with some significant subset of the above stupidity…

“ When you live on the shoreline, you can forget that there are people out there who don’t even know the ocean exists ”  —  Me Remember when you started in the world of Software Development (or, frankly, any field whatsoever)? How wide open the vistas were, how challenging the problems were, and  how much you didn’t know? And how, years later, the vistas are  still  just as wide open, the problems are just as challenging as they used to be, and you’ve realized that, if anything,  there is even more  that you don’t know? (•) The thing is, it’s not that you haven’t learned anything. The more in depth you get into a field, the more nuance you discover, the more weird/fascinating edge cases you find, and the more complexity you discover when you pull back the curtains.  Edge Cases  and  Nuance  essentially become the cornerstone of your existence, to the point where most of your discussion with your peers revolve around them. And the...

It really does feel like this gif sometimes, doesn’t it? Seriously though, look around at the folks that you are working with. Realize that, at the best of times, you’re spending about half of your waking life with them. Are these the folks that you want to spend this much time with? Is this what you want to be doing for half of your waking life? Yes, I know, most of us in the world don’t have agency. But, if you  do  have agency,  do something about it!  Evict those  #CowboyDevelopers  from your organization. Get the malcontents to stop malcontenting. Make change happen — you have agency!

So, you’re the new broom (•), brought in to Fix Things, to Shake Things Up, and to Take Things To The Next Level. As the new broom, it’s really easy to blame stuff on the previous administration, y’know?   After all, the developers are  clearly  not as efficient as they could be, there are  definitely  things broken in the product, and you were  explicitly  brought  in to “make change”. “It’s not my fault! ”, and “ Can you believe the mess the previous person made! ”   ← These are so, so easy to use, no? /via https://www.cherylmcmillan.com/not-my-fault/ Be very, very careful about if and when you deploy these though! The wise — and ethical! — thing to do is go for  Honesty  After all, given that the place  is  a mess, you will need to lay out the scope of the issues, the fixes necessary, and get buy-in on all of this. The end game, of course, is for people to internalize the existing issues, and the change ...

Hiring an expert is (somewhat)) straightforward when you need a very specific solution to a very specific problem i.e.,  you need  point expertise . For example, if you need a forensic accountant to figure out which one of your suppliers is short-changing you, well, you know exactly what to get. Mind you, I’m not saying you  can find the person — especially at the price point you need — but the pool of talent is very clearly defined. The thing is, most of the time you’re not looking for that kind of expertise . You’re probably not hiring a new Product Manager to build the same damn thing that they built at their previous gig — your people are different from the previous lot, the market has changed, the customer requirements are probably different, etc. What you’re looking for in them is what they learned in their journey at their previous company, how they juggled the competing pressures of scale, speed and scope, their interactions with stakeholders, and so forth. ...

You’re smart, you’re talented, you know what you’re doing, and  you don’t agree with Bob’s decision . Or, maybe, there is an ongoing discussion, and  you don’t agree with Alice’s position . Do you stay quiet? Do you object or argue? If so, how forcefully? The thing is, when you’re on a team, you don’t operate in a vacuum (yes,  even if you’re a  #CowboyDeveloper ). Yeah, “black and white” situations do exist, but most of the time you’re operating in a morass of gray. And within this morass 1. You might not have all the facts . There might be business pressures to go in a particular direction, sales opportunities, and a whole bunch more. Yes, you should, ideally, be privy to all the information necessary to make an informed decision, but sometimes (most of the time?) that is simply not efficient. it’s easier to delegate responsibility to the tech lead, manager, business lead, whatever. 2. This might be necessary for consensus . Yes, this may not be the wise...

“ That won’t work because … ”  —  #CowboyDeveloper response to any new idea that he didn’t come up with Look at the way your interact with others on your team. 1. What happens when you don’t know something — do you ever google it first to make sure that it isn’t a “stupid” question? If the answer on StackOverflow doesn’t make sense to you, are you hesitant to bring this up? 2. What happens when you make a mistake — are you reluctant to admit it? Do you hope that it won’t be noticed, or — gods forbid — see if you can cover it up? 3. What happens when you have a suggestion — do you keep it to yourself? Are you worried about getting smacked down by the resident #TechBro? Each of the above situations involves  taking a risk , by opening yourself to possible embarrassment or worse. The worst part is that it is  so  easy for it to be “ Yes ”, and every single “ Yes ” is an immediate hit to productivity, as tasks take longer to complete, mistakes are hidden, ...

/via http://www.savagechickens.com/ Meetings suck, right? I mean, sitting in that room, while Bob (•) drones on and on and  on , and you wish you were somewhere else, anywhere else, maybe even judging the Fingernails On Chalkboard contest, and it’s been 30 minutes  and Bob is still going … It doesn’t have to be this way. More to the point, if  you  have any agency, you can make sure that it isn’t this way. Everyone Talks Look around the table, and pay attention to the distribution of the conversation. Check out who hogs the spotlight (Bob!), who rarely talks, and who has checked out. The key point here is that you want  everybody  to have a voice, to participate, to be part of the team. Give the quiet ones a voice, and make sure that the inveterate talkers, well,  don’t  (if necessary, have a word with them before the meeting). Your aim in all of this is to enable a free flow, to have  everyone  participate, be involved, par...