Michael Lopp's Blog, page 38

How to Build Land

#

Ask Them How They Want to Grow

“We’re working on development opportunities for our engineering team including some of the most senior folks on the engineering team. What are some interesting things we can provide to help them with personal development?”

I get versions of this question a lot and I have some default answers that I list below, but I would be very interested in what others do to make sure they have credible growth opportunities for their team:

Let’s start with: sending folks to conferences is a fine idea and relative low cost, but I find conferences are a short term growth bandaid and don’t give engineers longterm fire/recharge. However, speaking at a conference is whole other deal that I highly suggest especially for the folks who think they are not good public speakers.
Vacation is never the answer to this particular question. Vacation is lovely mental opportunity to mentally wander and I’m a huge proponent of mentally wandering, but time off as a growth opportunity often translates to mental wandering that results in resignations.
Open sourcing an internal project is an easy short-term win, but the ongoing cost of maintaining said project needs to be factored into this program.
Work out an engineering exchange program with another company. Details here. I haven’t done this before, but it makes all sorts of sense.
Have an individual work on whatever the hell they want for 90 days. No constraints. Just their project. Extra credit for pairing them with other likeminded engineers. This is hard to pull off because there is always something urgent for these folks to do, but would you rather have them semi-absent for a quarter or absent forever?
Ask them what they want to do and how they want to grow. Like I’m doing right now.

What’s your power growth move for yourself or your team?

#

Your Best Work

I take issue with the deliberately inflammatory headline that Google is to blame for destroying the workplace since open office style workplaces were around long before Google, but the topic is worth debating.

I have a variety of issues regarding the open office trend. Let’s start with the fact that the folks often making the space decision are managers who already don’t spend much time at their desk because they are, by necessity, in meetings all day. They’re already in a quiet and private conference room where they can focus on the task at hand. They (we) don’t intimately understand the daily tax of constantly being interrupted because they (we) are not living it on a daily basis.

These same managers are often ones who are staring at the bottom line with the best intentions. With the increasingly painful rents in technology hotbeds like Palo Alto, San Francisco, and New York city, it just makes good financial sense to reduce the square footage per employee which means less walled offices because they consume valuable square footage. Don’t worry about the sardine factor, this smaller space will help create a more connected workforce and drive greater collaboration and innovation.

I appreciate the math because I’ve done it, but I get twitchy when fiscal responsibility is used a justification for maximizing productivity. This, my friends, is called a rationalization – a defense mechanism in which controversial behavior are explained in a seemingly rational manner to avoid the true explanation.

It is also bullshit.

In the past five years, the teams I’ve seen work at impressive speed are the ones who self-organized themselves elsewhere. They found a dark corner of the building, they cleared out a large conference room, or they found an unused floor of a building and made it their own. While this might strike you as a case for shared common open space, it’s not. It’s an argument for common space that is not shared because these teams have work to do and don’t want a constant set of irrelevant interruptions. This is why I’m in favor of pod-like set-ups where teams working on similar technology and projects have their own enclosed space. I believe this is the type of set-up that encourages the most efficient forms of collaboration.

A question: when do you do your best work? What are your ideal conditions? They vary by your personality type and whether you’re a introvert or a extravert or a stable or a volatile. If you’re a software engineer, your craft is code and you’re at maximum productivity when you have long uninterrupted minutes and each unexpected visual and auditory interruption is a unique opportunity to completely lose your train of thoughts, context, and hard to recover mental momentum.

The advantages of open space are undeniable: low friction access to the team encourages valuable serendipity, a lack of hard wall offices reduces perceptions of organization hierarchy, and there is an immeasurable subtle joy being able to look across the room and realize this is my tribe.

It’s a business and there are good fiscally responsible reasons as well as culturally ones to move to an open space, but who is doing the math on productivity? Who understands the compounding productivity interest earned with each consecutive uninterrupted minute of work? It is there in those hard to capture collective minutes where your best work is happening.

Rands Leadership Survey Update

Over 400 folks have taken the time to fill out the Rands Leadership Survey. Thank you. Some very brief stats:

I’m seeing a completion rate of 25%+ on desktops, tables, and smartphones which is a lot considering the survey takes 10+ minutes to fill out.
It is apparently easier to fill out the survey on a tablet. Higher completions, lower average time to complete. Tip of the hat to Typeform for making the survey simple and gorgeous on mobile devices.
98% of the folks who filled out the survey want to hear about the results. 92% are willing to joining a mailing list on leadership. That seems like an easy win.
In terms of where folks are willing to invest their time, the current winners are: participating in a mentorship program (67%) and semi-informal serendipitous bitching at a nearby bar (67%).

As I mentioned in the introduction to the survey, I’m leaving the survey up for a month and will then publish results. If you haven’t already and you are a leader of humans, take 10 minutes of your time and take the survey.

#

I Have a Hunch

Zach looked tired, he looked weary.

“I used to code. I’d get to work a little after 10am high on caffeine, I’d sit down at my desk, glance at my email, and then start coding. Sure, there would be a meeting here and there, but we’d be talking about code or things that lead to code. I’d meet with my manager at our 1:1, but it always felt like something he was supposed to do, not something that was actually valuable. 30 minutes. No big deal. Sometimes we’d even talk code.

“The team was growing fast and we needed another manager. I never really wanted to be a manager, but I was wondering what was going on in all those meetings, so… why not?

“Rands, it’s been six months. I’m getting in at 9am, I’m in meetings until lunch and usually through lunch. After lunch, I’m in hybrid hell of more meetings and dealing with whatever people and org crap has gone down that morning. I’m on my third productivity system and I have zero ability to predict what I’m going to do tomorrow because I’m reacting to everything that is happening today.”

And then Zach asked me, “Rands, am I ever going to code again?”

It Depends

The problem with solving Zach’s situation is that the correct solution is dependent on understanding a set of situational data entirely unique to Zach’s situation. The discovery of this data involves having someone with relevant experience asking Zach a lot of questions, asking his team a lot of questions, triangulating and analyzing all of the answers, asking follow-up questions, and only then designing a credible plan.

Zach knows that he needs help. That’s why we’re sitting here, but we’ve got an hour, and while I can ask a lot of good questions and make a handful of suggestions, I am guessing.

I’m a pretty good guesser because I’ve been working in engineering leadership for years, but I don’t actually know the specifics of the Zach situation, which means my advice might be credible, but built on incomplete knowledge. Furthermore, even if my guess is good, even if Zach chooses to follow it, his various situations are going to mutate as a reaction to the actions Zach chooses (they always do), and then he’s going to have more questions.

Who failed Zach? You could blame his manager. Based on what we know, Zach didn’t really know what was expected of him. He didn’t understand what it meant to be a manager, so he’s likely making it up as he goes. But making it up as you go isn’t leadership – it’s gambling.

You could blame HR at Zach’s company. They didn’t have leadership training, they haven’t set up mentoring relationships, and when Zach went to them for help, they responded, “Did you bring this up with your manager in your 1:1?”

You could blame me. I write a weblog on the topic and wrote a couple of books, too. Zach’s read the blog and both books and we’re still sitting here trying to figure out what Zach needs to do differently, but we’re guessing.

I blame everyone.

Collectively, I believe that we, the engineering leadership community on the Planet Earth, have done a poor job supporting each other. I think for every manager who has taken the time to find and regularly meet with a mentor, there are 20 managers who like the sound of mentorship, but haven’t done anything about it because they have no time. And even if they did, they wouldn’t know where to start.

I think that there are well-intentioned HR teams who are building leadership training without partnering with their engineers. Similarly, I think there are legions of engineering managers who have been asked very politely by their HR teams to partner on building said programs and those managers have politely and repeatedly said, “I’m too busy.”

I blame everyone. We can do better.

Bookshelves are full of unread books on leadership written by authors who have never managed engineers. Authors who are clever with a turn of a phrase, but who have never written a line of code. Authors who did write code ten years ago, but still think in terms of software that was developed for 18 months and shipped in a box. Authors who inspire, but fail to deliver.

I Have a Hunch

I have a hunch that we engineering managers can collectively better help each other. I suspect that there is someone sitting relatively near you who would like to help you, but you have no idea that they exist. I believe that if there were readily available events, talks, and dinners where we could sit down and honestly talk about the craft of management, that we would instantly make time because I do not doubt we have a desire to learn and to grow.

I have a hunch that we don’t miss coding: we miss engineering. We miss the tangible sense of accomplishment of building a thing, so we should view the job of engineering leadership as an engineering problem – that means we must solve.

I wrote this survey because while I think we can collectively help ourselves, we need to determine a credible and high value starting point. If you choose to fill out the survey, you’ll be answering questions about yourself, your leadership situation, your current leadership pains, and what leadership investment activities would most appeal to you. Please share it: the more data the better.

I’m going to leave the survey up for a month and then I’ll write up the results. From there, we’ll start building.

What You Actually Want for Christmas

#

What a failing hyperdrive sounds like…

#

Aperture Science Innovators

By Jake Briggs and purchasable here.

#

The QA Mindset

My first job in technology was a QA internship. The summer between my freshman and sophomore years, I tested the first release of Paradox for Windows at Borland.

As an intern, I started by following someone else’s QA test plan – dutifully checking each test off the list. After a few weeks, I knew my particular area inside and out. A new build would show up, which I’d install via 3.5-inch floppies, and in ten minutes of usage, I’d have a sense – is this a good or bad build?

In QA, there is a distinct moment. It comes once you’re deeply familiar with your product or product area; it comes when you’re lost in your testing, and it comes in an instant. You find a problem, and because of your strong context about your product, you definitely know: Something is seriously wrong here.

Where’s QA?

At the current gig, there’s no QA department. QA as an independent function does not exist and that’s a first for me.

Every company I’ve ever worked at, for the better part of two decades, whether consumer or enterprise software, has had a well-staffed QA function. I’m told this absence is not unique in the Valley. I’m told that both Facebook and Twitter don’t have a QA entity.

Similarly experienced co-workers keep asking, “Shouldn’t we have a QA function?” and while my instinctive response is an emphatic “Yes”, as a member of a rapidly-evolving profession, I need to be open to the idea that software development evolves in ways that may seem counter-intuitive to me. The fact that the team and the company have been successful sans QA is essential and interesting data.

My thesis regarding the necessity of QA has always been: checks and balances. A healthy development team was one that had engineers doing their best to build a great product. These engineers were paired with a team of QA engineers who were doing their best to prove the product wasn’t great. These conflicting goals result in what I consider to be an essential healthy tension between engineering and QA.

Yes, there is often professional conflict between the teams. Yes, I often had to gather conflicting parties together and explain that, “You are both doing your job. No, engineers are not deliberately creating bugs. No, QA is not hating on the product. Yes, we actually have the same goal: rigorously confirming whether or not the product is great.”

The absence of this healthy tension concerns me, but more worrisome is the absence of the practices a thriving QA function builds and maintains. These practices are still with me and are essential to defining and maintaining a high quality product.

They are:

Do I understand the issue?

It’s natural to get rage when software doesn’t work, especially when you paid your hard-earned money to purchase it. Rage is counterproductive to the QA mindset. In fact, it hinders it. The QA reaction to defects is curiosity: Whoa, whoa. Wait, what happened there…? And what follows is a series of interrelated questions that build on each other.

Can I reproduce it? Does it happen every time? What was I doing right before the situation occurred? If there is a crash, does the crash log offer any clues? Based on my knowledge of the product and the code, do I have a hypothesis as to why this might be happening?

In the last decade, software companies have made the process of capturing crashes stunningly easy thanks to the Internet. When your application or operating system crashes, you often receive a dialog delicately apologizing for the crash and asking if you want to submit a crash report. Usually you are asked if you want to add any additional information, and usually you don’t do this, which leads us to…

Can I effectively report the issue?

In this world of auto-submitted crash reports, we the customers have little incentive to provide any information beyond the crash report because we’re mad. Our software crashed, our game was interrupted, our document was lost, value was not delivered. The QA mindset dictates that “Any additional informational, however seemingly trivial, might aid in the resolution of the issue.”

You probably do not take the time to add any additional information when these crashes occur, or if you do, it’s full of rage: “JUST TRYING TO GET WORK DONE HERE PEOPLE.”

Some bugs are slippery. They exist at the intersection of improbable and unthinkable. This is why these bugs are discovered in the wild. Humans do strange shit to software that we could never predict in the controlled setting of our carefully constructed software development environments.

Slippery bugs are a mystery, and there is initially no telling what contributing factors are relevant. In my time in QA, for issues that were hard to reproduce, we prided ourselves on documenting everything, however irrelevant, that might have lead to the crash. Totally clean OS – just installed. Wired connection, wireless disabled. No virus software. All files are local.

You’re not going to do this because you don’t perceive that you have skin in the game. You’re correctly assuming that part of what you were paying for is quality, and you likely haven’t been in QA. You likely haven’t received that mail in the middle of the night from the development team, who has been chasing that slippery bug for the past two weeks where they ask, “Can you try this patch? We think we fixed your bug.”

And they did. Because you took the time to think before you submitted your report, which leads us to our last part of the QA mindset…

Do I perform these actions unfailingly?

The last QA dictate is the most important and the least likely one that you perform. The last dictate is: “In the face of a problem, do you act to correct it? Unfailingly?”

There’s a bias towards system and applications crashes in the observations above because these crashes are the defects that give us the most rage. And while identifying and fixing these crashes is an obvious high priority, there’s a whole other class of defects of equal priority that are less obvious.

My favorite internal application at Apple is a product called Radar. It’s a Cocoa application that served as our bug tracking system, and if you wanted to know what was going on regarding a specific application at Apple, you went to Radar.

For many groups at Apple, Radar was religion. An issue regarding a product was not considered to exist until it was in Radar. If someone asked me, “Have you seen this bug in your product?” My immediate response was, “Is this in Radar?” “No.” “We’re not talking until you’ve filed Radar.” Case closed. For now.

The unfailing rules were:

If you see something wrong in the product – however big or small, report it as best you can.
It is good form to take the time to report the issue as descriptively and thoroughly as possible, but it is more important to report the issue.
It is also good form to check if the issue has been reported by someone else, but it is more important to report the issue.
When the issue is reported as fixed, take the time to confirm it as such, because more often than not, it’s not and/or it created another related issue.
Failure to follow these rules will be met with an immediate reminder of the aforementioned rules.

For the teams that unfailingly followed these rules, Radar became a powerful tool because it became a credible source of truth regarding the product. The answer to the question, “How is the product doing?” wasn’t an annoyingly vague, “I’m feeling good about it.” The answer was, “We’re fixing critical issues at a rate of 1 issue per engineer per day. We’ve got 14 engineers, we’ve got 308 issues, which means if no issues arrive, we’ve got 22 days of work. Except our arrival rate is 7 a day and it’s increasing. Also, next time you want to know this data, here’s the query you run. Stop wasting my time.”

You are sensing rage in my answer because I’ve spent a career surrounded by well intentioned humans who believed that it was QA’s job to file bugs, and the fact is that quality is a feature, so like it or not, everyone is in the QA department.

QA is a Mindset

In a pre-Internet world, one of the key reasons for a well-defined quality assurance team was the cost of distribution. When you released software, it required producing a pretty shrink-wrapped box full of disks and documentation. This was expensive to build and ship. More importantly, the infrequent yearly release of this shiny box was the sole yearly opportunity to get your software in front of your customers. It could be upwards of a year before you had a chance to right your buggy wrongs.

Thankfully, blissfully, this is no longer the world we live in. At the current gig, we’re releasing the website a couple times a day. We’re releasing apps at a slower pace, but when I say slower pace, I’m talking days… not months… never years. Perhaps our collective ability to not only rapidly detect, but also fix issues within our products, has made us less dependent on relying on an independent QA function?

My concern is that the absence of QA is the absence of a champion for aspects of software development that everyone agrees are important, but often no one is willing to own. Unit tests, automation, test plans, bug tracking, and quality metrics. The results of which give QA a unique perspective. Traditionally, they are known as the folks who break things, who find bugs, but QA’s role is far more important. It’s not that QA can discover what is wrong, they intimately understand what is right and they unfailingly strive to push the product in that direction.

I believe these are humans you want in the building.

The Force Awakens – A Collage of Iconic Images

(This brief article assumes you’ve seen the trailer. If you haven’t what are you waiting for?)

The Return of the Jedi came out on May 25, 1983 which is really the last time that you saw new material on the Millennium Falcon was 31 years ago. If you were alive, close your eyes and imagine what you were doing 31 years ago. I was furiously begging my parents to let me see Return of the Jedi again.

As teaser trailers, The Force Awaken checks all the boxes. Introduction of characters. Check. Establish that the Star Wars universe has evolved since we last saw it. Check Bad guys. Check. Good guys. Check. Potentially annoying guys (Rolling ball droid?). Check. Lens flare. Check. Tip of the hat to the original series. Check.

Based on reaction of the rest of the family, everyone is excited to see the movie, but the trailer does little to introduce where the story is headed. It’s a delicious collage of iconic images. For me, there is only one shot that matters and that is the Millennium Falcon. We had a hint of the Falcon in Episode III as a much earlier version of the ship is docking in Coruscant, but that was three seconds and who knew who was flying it? We don’t know who is flying it in the trailer, but there is high probability it’s folks we know.

The Millennium Falcon is all I needed to see. I’m hooked.

#