Engineering Is About More Than Code

Curiosity is what drives engineers, and is equal parts curse and companion. An engineer isn’t limited to development or operations. An engineer would be a problem-solver in both areas, probably more. Curiosity is a surprisingly rare quality in people, even in technology.

If you want to know how something works, take it apart and observe. My first digital systems disassembly was a Sony Discman in 1989. Whatever I did, I fixed it. The feeling was powerful. It just took me 25 years to realize that there are many broken things in the world and to prioritize which one’s I involve myself with. Understanding the problem is crucial.

This is how I approach many conversations, navigating purposely and politely until there’s a useful reframing. People aren’t things, so be kind, be sensitive, and be patient. When you engage, learn about their biggest challenges, how they approach things, and what drives them. Just start with that.

[If my 80’s discman was still around, it would be like “yup, those were the days”. My 8086 XT clone next to it would splutter out some op codes. My Mega Man game watch would be waterlogged and stuck in a loop. Which all lead me to the next action…]

Put things back together again so that they work, hopefully, better than before. It’s just courtesy. In commit-worthy code that’s called hygiene. In conversation, that’s called maintaining a shared view or vision. Do these things enough and you’ll find that the way to a common goal is easy easier than with clutter obscurring your journey, and for others’. When you can row in the same direction, you get to your destination a whole lot faster.

Put it with other things to see where it doesn’t work. That’s integration and it’s not always easy, especially if it’s your own code or new auto-scaling configuration that causes unforeseen things to blow up. Get to know what your thing does before and after you put it out in the wild. Be honest with yourself and others about the time this takes.

There are some things you can take apart, and some things you can’t. If you can’t or if it’s too much effort for not enough value, move on to another learning tool, but remain committed to your goal. In the light of fundamental flaws in how we think about security, privacy, and basic human welfare right now, seek something you’re proud and grateful to do. [There are some very worthy things happening in Boston right now.]

How to “Hire” into a “DevOps” Market

Let’s be clear. I’m mostly writing this so that I don’t have to have another bullshit conversation with a high-level agency “technical” recruiter that doesn’t really know what the hell DevOps really is. But before you misinterpret what’s to come as a horn-rimmed trash session on recruiters (only a motif, I promise), consider that had you not read to the end, you would never have learned how to hire more efficiently, effectively, and ethically.

Boston, We Have a Big Problem

Aside from the occasional scuffle at a Java meetup, I’m in the Greater Boston Area, and Boston isn’t exactly known as a shining example of the tech boom. Sure, we have Facebook, Amazon, ZipCar, TripAdvisor, Chewy, RaizLabs, and Pivotal amongst others. We also have Oracle, IBM, Salesforce, and a plethora of other institutionalized madness from the Fortune 500 which typically drags our communal technical proficiency rating down year after year. We also have some of the most dedicated, seasoned professionals which you’d be hard-pressed to find in Silicon Valley during a fictional OSCON meets AWS Re:invent meets RSA all rolled into one.

Our problem is hiring. Everyone everywhere does not have the problem quite like we do. Its potency is not diminished in the DevOps space simply because its a generally applicable point to make for any highly skilled market. When something is as culturally intertwined as True DevOps mindset is in high performing teams, traditional recruiting approaches will always fall flat on their face. What people are calling DevOps positions right now are a loose collection of uninformed guesses, buzzwords, poorly crafted hiring pitches, philosophical paradoxes, voodoo, and outright corporate misunderstandings.

Recruiter, Know Thyself

What’s required is simply a sea change in recruiting mindset: the fastest way to qualify people is for you to qualify yourself. I don’t mean credentials, I mean the way you ‘smell’. Not by your morning shower and shave, but by what real practitioners need to hear from your mouths in the first 30 seconds: “I’ve really been thinking about how to right-fit you and a few of my clients,” or something equally real and challenging. How about “I’m interested to know what kind of work you’d like to be doing…” or “Which do you like better, people or code?” (that one is for all you recruiters looking to place the even more elusive ‘DevOps Manager’ position, which as it turns out is just a normal technical manager that’s passionate about coaching and improvement and customers and building future leaders.)

Or you could just leave us really good hires out of it, focus on the email overload flowing from opaque B2B recruiting firms currently choking your inbox (yes, I have recruiter friends and we talk), and then you’d be bidding for the lowest common denominators and margins, not the highest ones. Good luck with that approach, it leads to burnout and we DevOps people know a million ways to get burnt out. But unless you’re ethically fine with placing unqualified people with unqualified teams for a buck, the first option is better for you and for everyone you churn through week after week.

Be Transparent..to a Fault

Recruiters and hiring managers, there is nothing worthwhile to hide from someone like me that isn’t abundantly already transparent through what you don’t know about the organization you represent. I don’t have to ask questions about the org, just about you and your relationship with actual decision-makers, and what you don’t understand or know enough about to hire on behalf of True DevOps teams properly.

To get over cursory technical qualifications, ask people for examples of their work, or better yet look for them first; the simple act of a prospect answering you with examples of their expertise (or simply knowledge to-date) in particular areas is something unqualified people can’t do and unmotivated people simply won’t do. If your candidate hasn’t used any of a dozen or more social platforms (like Stack Overflow, Medium, LinkedIn, etc.) to publish their own stuff, encourage them to so you can pass it along to the real decision makers.

Once these minimum-viable qualification hoops are behind us, bring something to the table. Have a spine and a brain and a perspective about the challenge you’re looking for my help to solve in an org. Understand the broader issues the organization you’re representing is having, then ask us which ones we think we actually have the desire and a real shot at helping to move forward.

Suspend disbelief for a moment…

Drop the bullshit. Tell us who your client is when we ask, how many and which positions they have open, how many other candidates you’re playing off each other for some high-dollar plot of glory, and for god’s sake be prepared to describe your client’s *engineering culture* like it was your own family. Go to a meetup every so often, or better, help to organize one. Sit through and listen, stop emailing from your phone through the presentations. Absorb what’s happening, how people respond to certain topics, and if you don’t find yourself startled awake by clapping, you may just learn something.

Against all corporate recruiting conventional wisdom, when a potential candidate comes at you with such Maslowian questions as “Can you tell me a bit about their culture?” and “What challenges there would I even be interested in?”, definitely don’t talk about benefits packages (that are mostly all the same at a certain level anyway) and please don’t use things like “occupational environment”, “team synergy”, or “interpersonal skills”. Please be real, explain to us what you do so we can understand if you do it better than anyone else we will talk to that week, and leave the qualification script at the door.

You’re selling you to us first, then you earn the right to sell your client to us. If the order of those two things is in reverse, it’s equally transparent where your placement priorities lie.

Hiring Managers: Who’s Doing Things Differently?

Off the top of my head, I can think of a few folks in the local Boston DevOps meetup that are good examples of how to place highly qualified practitioners:

  • Dave Fredricks, Founder, eninjia.io
    This guy is legit. Hard working, constantly advocating, and an early organizer of DevOps Days Boston, amongst other dedicated individuals.
    .
  • Sam Oliver, 3yrs self-employed recruiter, now FTE at PathAI
    This woman really rolls up her sleeves, as a co-organizer of the Boston DevOps meetups, and smartly carved out the “we’re hiring” pitches from the “let’s talk tech” conversation that this crowd is known to like as separate things. #listening
    .
  • Kara Lehman, Principal Recruitment Consultant, Huxley
    Her stock is climbing with me. We first chatted it up in 2017 and when I asked her what she was doing at the nerd-fest of a meetup at Pivotal, she said that she “needs to understand this thing called DevOps better”, which is far more enlightened of a response that about 99% of other local recruiters.

If your name isn’t in the above list, nothing personal, I’m writing this at 10pm on a Monday. Let’s have a conversation where I vet you out and then maybe I’ll write about you too. In the mean time, prepare yourself because it will be me who’s interviewing you.

Apologies and Thanks

If you got this far, my gift to you is my true gratefulness for feedback you may have and maybe a retroactive apology for saying things harshly. We need to cut through bullshit, especially the corporate flavors of it, and this is my personal blog anyway.

Recruiters: if you “can’t do these kinds of things” in the position you’re currently in, consider that you would probably earn far more by taking a new  approach (like the one in this article) on your own and making 100% commission on your own closes instead of a measly 50k/year plus.

Also, you can also reach out to me via LinkedIn and let’s talk about your challenges in hiring, training, managing, or fostering a DevOps-minded team. I’m much nicer in person than in this post.

More on DevOps:

FUEL for Your Brain: On Focus, Usefulness, Execution, Learning

I hate acronyms. My dad used to use them far too much, the kind of guy that was more smart in retrospect than the kind of boy I was understood at the time. Kind, thoughtful, quiet, and invested in people around him.

My current thought product is an acronym, “FUEL”, based on a few key practices that I find are valuable to my current line of work as a Change Agent. These practices take time to develop and are only truly useful when used in parallel.

  • Focus: ability to right-size activities to close the task(s) currently underway
  • Usefulness: ability to gauge effectiveness of work and reprioritize based on new ideas/objectives/activities
  • Execution: ability to match skill to task, collaborate the plan, and resolve blockers as they arise
  • Learning: ability to observe outcomes and refactor them into useful ways to improve all of the above

Real-time Example of FUEL

Last night after a meetup, I had a beer with someone I’d met before at a local conference but hadn’t dived into. The opportunity presented itself, so I stayed a little later than I normally would. They are a CTO for a 50-person startup in town. Net-net:

Paul: “What’s weighing on you right now man, work related?” (L)
Them: “Kind of glad someone asked…we have people issues.” (E)
Paul: “You’re not alone…what kind?” (E/F)
Them: “There are a few ‘senior’ engineers that don’t produce like others.” (U)
Paul: “What’s your plan for them and the rest of your team?” (U)
Them: “We just laid off one after giving him a path, but the other two, I don’t know…maybe add metrics, visibility…they’re kind of SPOFs.” (U)
Paul: “…so you can quantify what you already know? How did we arrive here?” (U/L)
Them: “They were here at the beginning, hence ‘senior’, but one guy hasn’t committed code since Sept (5 months)!” (E)
Paul: “Got it, they don’t ‘git’ it. [laughs] How are you and the leadership team  helping to coach other junior engineers?” (L)
Them: “Well that’s the problem maybe. We don’t exactly have a culture yet, but our C-level relationships with each other are solid.” (U/E)
Paul: “I once heard that great leaders define their success by fostering other leaders. Do you know who your real ‘senior’ engineers are?” (F/L)
Them: “Well I kind of already know who deserves the chance to step up.” (E)
Paul: “That’s good, but not enough. People often hesitate on new things simply because they haven’t experienced how it works yet. Your coaching needs to help those people get over any blockers to proving one way or the other if they can do the job well/right/better.” (FUEL)
Them: “I’m going to talk to our CEO about this. Can I get your card?”
Paul: “Only if you intend to use it.”

Good enough exercise and learning for me for one night.

 

Kindness: What Makes a Great Technical Team

How do you quantify what makes a great working environment, a good team, and work worth doing? An important piece for me is kindness.

Kindness is Human

At the risk of speaking to some stereotypes here, kindness is incredibly important in teams where members often lack patience and social skills. It doesn’t have to hinder honesty, expedience, or effectiveness. In fact, showing a small amount of kindness in your daily interactions reminds the people you often work most closely with on otherwise dry, tactical topics that there’s more to work than just code or tech. It reminds people that both you and they are human, not software-delivering carbon units.

Kindness is Engaging

When you show a little kindness, maybe a bit of sympathy about how frustrating a specific framework or project is to the team, it allows people the opportunity to open up if they want to. By sharing a short, discrete moment where you’ve felt the same excitement or frustration for a technology, you’d be surprised how often it elicits candid conversations that you’d otherwise not have during normal sprints or reviews. It gives people the cue that it’s okay to be themselves a little.

Kindness is Strategic

Looking for a promotion? Counter to kissing ass with a boss, expressing a little kindness to everyone you work with signals to intelligent management that you pay attention to social cues and understand how to play well with others.

Again, the level of kindness you show shouldn’t detract from your efficiency or ability to be straightforward at work; it should enhance your efficiency by proactively smoothing the interactions you have with co-workers, partners, and other non-technical folks.

Kindness is Admirable

Everyone has bad days. It’s how we deal with them that signals to others how professional, reasonable, and capable you are when you get down to business. And let’s be honest…technology is a revolving door. The relationships you make at one organization can indefinitely benefit future positions you may hold. Just as honesty and effectiveness are qualities people remember, being unkind never gets you on the list of people that others want to carry with them to the next gig.

More reading:

7 Practical Tips for Inclusion

This chick I know, I interviewed her last week for my upcoming podcast debut. She’s phenomenal in a way that makes me so proud, grateful and humbled all at the same time. Sufficed to say, I found a place to put one of the ideas I had been holding on to ever since I started going to the Women In Tech group at my work:

“Practical Tips to Help White Dudes Help Out”

Trust me, I’m a subject matter expert on this. I’m so white, I made the vanilla ice cream we had for dessert tonight say “daaaaammn!” (then I ate it up). And though I’m not into sports and don’t have lots of chest hair, I am definitely dude.

I’m the kind of dude that wants to help. I have a son and daughter and I want the world to be a less sexist, less broken place by the time they are out in it. It’s that attitude I look for in others, not the other things that differ between us.

Yet it still remains, there are huge imbalances in society no matter what angle you look at things from. Good intention matters a little, but action in the face of injustice matters a whole lot more. It’s what you do that defines you to others most because only a few people in life will ever spend the time to see past that.

What Can We Do to Help?

The difficulty with things like gender inequality, under-representation, privilege, and inclusion is that they’re too nebulous/vague/ethereal for the side of the crowd that can/should/doesn’t do something about it, namely white dudes, to take action on a daily basis. It’s not that we’re white or that we’re dudes, but for whatever reason, many dudes just need practical instructions, marching orders, or technical requirements to move from well-meaning to noticeably effective.

So I wrote some specific tips down. Their implementation might differ from person to person, so I wrote them in their most generic form:

WP_20160214_004

Since they aren’t exactly marching orders, more fortune cookie mnemonics, I’ll put down some examples. They apply to all people, not just dudes to women, white people to everyone else, they apply to people who want to help other people. For the sake of this article, I’ll write it as instructions to my fellow white dudes:

1. Step up by being willing to step aside

Instead of offering your own idea, ask a co-worker for her opinion first. This works best if you do it once or twice casually on a personal basis before doing it in a group or meeting.

Doing so privately before hand can establish trust and help you understand if it’s appropriate to do so in a group setting like a meeting, so that you don’t accidentally put them on the spot.

If you do successfully help to elevate someone else in a group, congratulations you’re using your white dude privilege properly, that’s why you feel good.

2. Invert the situation in your head

When people address a group as “guys, guys”, think about what it would be like if you were in a group and someone addressed you as “ladies, ladies”. It’s a trite example, I know, figure of speech, but ask yourself: why is there even a gender associated with that figure of speech? #culture

When was the last time you heard the words “aw, it’s so great to see a man programmer, really brings some diversity of thought into the group”? or “really? you like beer? are you sure you don’t want some wine or a fruity drink?”

Gender/racial/sexual bias is baked in to _every_ aspect of American life, so there should be plenty of opportunities to invert the situation and see how subjugating it would feel to be on the other side of things.

3. Learn where the gaps are around you

Be willing to ask your human resources department to provide you statistics of gender, race, and ethnicity in your organization. Look around at how many black dudes or women are in your group? How about people from outside your background? If they say no, ask why? You can’t be fired for asking about this stuff. If you are, then be glad! You’re no longer working at the wrong place to work.

4. Don’t chalk things up to a stereotype

Please, white dudes, please do not in your head justify the actions that a woman is taking with the fact that she is a woman. Do not think that he’s thinking that way because he was raised in the ghetto (a.k.a. where all ignorant white dudes think black people come from). And for the love of whatever, please do not justify your homophobia by saying “so long as he doesn’t try to hit on me, I’m cool with it”.

Stereotypes limit people to presumptions you have about them regardless of their actions, which are the one thing we all control about ourselves. Reduce how someone chooses to put themselves out into the world, and you reduce your capacity to see clearly, to respect, to love, and to be loved.

5. Listen; be more interested than interesting

I will never reach a point where I can’t get better at listening. I’m terrible at it today, I hope to suck at it less tomorrow.

The more you listen (awareness), the more you maximize your opportunities. It’s that simple. Action without listening is ignorance.

The practical way to do this is to write “STFU” on your hand, on your notepad or tablet before a meeting, or picture everyone in the room having it tattooed to their foreheads.

When you actively listen to someone, you express interest in them. People like to feel interesting, just like you, and giving that feeling to them as a gift is not a complicated or expensive affair. Both parties win in the end.

6. Find a liaison, socialize, and invite

It’s intimidating to visit someone else’s group or circle. The easiest way to smooth that social gravel is to have someone native invite you and liaise between you and the group.

This puts a responsibility on you to be inviting and socialize people not in your group. It also puts a responsibility on all of these groups to be inviting and look for opportunities to become a liaison too. Yes, I’m calling everyone out here.

Women in tech, take the time to bring a white dude to group. Black people, there is so much I don’t deserve, but the privilege I have you’re welcome to it so long as you’re my friend. We share friendship, we share privilege. That’s one way to get things flowing in both directions.

7. Don’t let failure stop you from trying again

All of these things will feel awkward, not just for white dudes, but for everyone involved. Creating something new doesn’t come easy. Easy is comfortable. If you’re going to be uncomfortable, let it be because of something worthwhile.

Other people are worth it. Try again. Don’t push it…if you’re doing #5 well, you’ll know when to back off. But don’t let failure stop you from doing the right thing. If there are others doing the same, the effect of trying will multiply itself in time.

CTO vs. CIO: How many tech “corners” do you really need?

Have you ever thought about what “departments” really means? The word “department” starts with another word: “depart”. Stop, think, continue reading.

Technical Chief Officer’s Dilemma: Departments and “Agency”

Are you in a situation where you honestly need people who purposely segregate themselves into groups that start with a departure from each other, rather than a congregation of ideas, people, and purpose?

If you are responsible for a technology “department”, you are responsible for a “failure”. #explain

Consider a geometric line, the most efficient way to connect one point to another. If only people were that easy. Get enough of them together and you start having to group them into manageable departments. IT, Development, Operations, Finance, Sales, Marketing, Management. Business lines to make things easy, right?

Departments are “Depart”-ments

Wrong. Department f*ck screw things up. Drawing lines isn’t a good thing unless if it’s to connect people with each other. They distract people from the simple truth that businesses who succeed are filled with people who instinctually understand that they are all on the same path, together.

Consider a geometric shape, the triangle. A line plus one point, an important point, an entire dimension. What good does it do to add another point beyond that? A square? Another department? Finance? HR? Marketing? Why?

I’m minimizing, I know wonderful, necessary in finance and human resource. Apologies to them, it’s just to make a point.

Only the Right Lines Need to Be Drawn

People who work with very large organizations know this inside out. Enterprises, government agencies, financial institutions. Corporations. The more lines there are, the more overhead and lack of progress there is. Sure, there’s stability, structure, fortitude; but the further we get away from connecting point A to point B in a straight line, the less efficient we are.

Truly effective business starts with figuring out how to define things with the least number of lines. Communication, organization, collaboration all benefit from simplifying how many lines are drawn. #karma

More reading:

DevOps, Burnout, and the Search for the Holy Grail

I’ll be speaking at APIdays Melbourne about the technological equivalent of the holy grail, continuous deployment, and why maybe we should re-think certain dynamics coming from the push to “do DevOps”, which like many good ideas is marred by poor implementations and shotty management.

2/2 Update: Things come up, shit happens, and I am incredibly bummed not to be able to be part of the crew at APIdays Melbourne this time around. However, priorities are priorities, and I’m not going to regret missing the 18 hour flight there and back.

Grateful for the opportunity, hope this doesn’t burn bridges, but sufficed to say I’ll be there in spirit. Thinking of shipping a TelePresence bot and asking @switzerly to set it up for me. 🙂

I’ll still be looking to find a more local forum for this talk, hopefully at APIstrat.

Of course, I’ll be showing how to inject comprehensive testing into a pipeline of API design, build, deployment, and monitoring tools, but I’m a people person more than anything else, so germane to my presentation will be the topic of how “doing DevOps” affects us at a personal level too.

Humans are tool builders, not the other way around.

Why are we talking about DevOps?

I love the ideas coming from that space. Any time people work closer, tighter, better together, I’m down. But revenue doesn’t care about you or me, and the impetus behind most practical implementations of continuous delivery are indeed revenue, over-trumped expectations from the business on IT as their main blocker rather than proper decision making.

Often the result of forcing unprepared teams to “do DevOps”: #burnout

In November at APIstrat Austin I stood up and said that teams are more important to get right than the software they produce, though they’re both very important. People produce software. If the people are buggy (i.e. bad team dynamics), you will see that in their product.

At the company kick-off last week, I sat in the front row as a panel of exec-level customers validated that the immense pressure to release software faster than ever before is real, is connected directly to revenue (loss not just gain), and is incredibly challenging due to people problems more than just technological ones.

Business leaders looking to implement new paradigms on technical teams will also find it surprisingly hard to “do DevOps” if there are cultural or personal issues laying around like land mines. From my last job, I know this first-hand.

I’m a Developer, but My Cape is at the Dry Cleaners

15 years professionally and counting. Right now, I see that code written in an IDE isn’t the only important factor to bringing excellent products to market. Code of conduct in teams, the responsibilities a business has to its employees, and how we treat each other along the way to building world-class software are just as important for a sustainable business model

Sorry startups who “do DevOps” because it’s cool, call me in 6 months if you still exist and want to talk for real. I would *love* that as a podcast interview episode.

For now, like an underwhelming version of Clark Kent, I temporarily hang up my [developer] superhero cape, put on thick-rimmed glasses, and work a job in the big metropolis during the day. I am educating myself and rounding out my ideas on what it really takes to be in cutting edge technology. I surround myself with very driven, passionate, fun, and smart people to get better…at everything I can.

I am expanding my understanding of how to bring about great technology beyond what an IDE can provide me. I work with people, code, and businesses.

More reading: