It is common understanding that in my world of software that Product Management and Engineering need to be separated; when you design your organization the Product Manager cannot report within the Engineering section of the tree.
Engineering is a bad omen that Product Management must be protected from. Product puts the user first. Engineering puts technology first. The evidence we have speaks to this truth. But it doesn’t have to be this way.
It wasn’t always this way. Xerox Parc had zero product managers. Hell, you could argue it didn’t have any users. It was pure engineering research. It took other companies decades to bring their accomplishments to the masses. What the engineers at Xerox Parc did pushed the user experience of computing forward unlike anything we have seen since. Not simply technology, but the actual experience of using it.
We absolutely need Product Managers. But the reasons for this divorce lays squarely at the feet of the Engineering departments. Business have created separate Product departments as an organizational immune response to defend the value of their users.
There are a number of pathologies at play. Often engineers chase technology in the form of “resume driven development,” or point to certain technology as the reason they cannot improve the user experience. Sometimes it is simply choosing to solve a technology problem with minimal value to a user, while ignoring higher value problems for users.
Engineering departments needs to remember what this is all about. Creating value for the users of our software by solving their problems—both the ones they can clearly identify, and especially the ones they cannot. I worry that we won’t have any more breathtaking advances in technology because we are only solving intricate problems that we suffer from. This work is necessary, and helpful, but a far cry from the world-changing inventions we tend to promise the world.
We are riding high right now, being compensated very well for our work. Are we overpromising and under-delivering? That is a recipe for irrelevancy.
Read more: Product vs Engineering
Releasing code to production is a process. The process has to be quick, simple, and repeatable. If that process is slow, or wrought with problems and caveats people aren’t going to want to do it. Just like water follows the path of least resistance—so do people. If it is easier to not release something it won’t be released.
Releasing code to production is also a muscle. If you stop exercising it will atrophy. Your ability to create production code will suffer.
Code that isn’t in production is not producing value for your customers, and thus your company/organization. Production is the only environment that matters (this is why we also “test in prod”).
Increasing your mean-time-to-release means shipping code faster and more often. If this muscle is strong the world is your oyster. Once you identify opportunities you can move on them, because your shipping muscle is strong. Once you identify problems you can fix them, because your shipping muscle is strong.
Shipping small pieces quickly is also a de-risk strategy. Making small changes reduces the surface area for problems. If you ship one small piece, and something breaks you know precisely where to look for causes. It doesn’t even have to break—if behavior changes in your system, or even your users, you know what caused it. Because you shipped a small change.
If you ship a giant overhaul, and something breaks—good luck finding it quickly and fixing it quickly. The risk of large changes is larger than just the size of the change. Thanks, network effect.
This is not about “being fast”, or “being faster than the competition.” MMTR is a process and a muscle. It sharpens your ability to write production-ready code, because you’re going to ship it right away. It de-risks problems by observing what happens in your systems after each small change ships. It allows you to be nimble and respond by creating value for your customers. After all, it is about what you can do for them.
Read more: MTTR is the Most Valuable Piece
This is my favorite aphorism. There are so many important things that need doing to deliver value to users. Commits don’t matter, especially when they’re the wrong commits!
It is an unfortunate trend to try and capture productivity levels of engineers. Lots of companies are trying very hard to create a new Fordist movement for knowledge workers. It’s not going to work (not currently anyway).
More and more of engineers time these days is required to be spent on non-coding activities. Make sure your organizations recognize your effort here. Make sure they reward your effort. Push to get those on your career ladder/promotion evaluations.
The purely head-down programmer who isn’t looking at the broader picture is not going to be very successful going forward. There is too much to learn—one person cannot know it all. Things are changing too quickly. And users are becoming more sophisticated, and demanding.
The tech industry is healthier when people are buying their software. Not our current VC-funded where the users are the product and engineers live in silos separated from the population. But in order to get back to a place where people buy software we have to have our eyes up.
It is my opinion that if an engineer is unable to value the efforts of other engineers to “be the glue that keeps projects going”, there is no way they’re going to be able to value their users and look them in the eye.
Read more: Valuing Glue & Eyes Up
I am so very grateful to have found this talk. Thanks to the person who put this either in Slack or on Twitter so I could watch it. Thanks to Etsy for publishing it.
I never had a word for my particular affliction. But let me set up the scenario. There are two worlds: convex, and concave (for the details see the talk). Kent utters a phrase that I identify with deeply:
For me projects are over the first time somebody says “That might work!” Ugh, I gotta find a new project now.
I suffer from this. Once the project I am working on has no more tough puzzles. Nothing that needs research or figuring out. All that is left is typing and moving the code around on the screen until its “pretty”, or refactored, or “architected”, whatever description you prefer really. That is when it becomes tediously boring. I know how to get through it; I’ve shipped a lot of software in my day. But as Marie Kondo would ask: “Does this bring you joy?” No, it does not. I am addicted to the endorphin hit of learning something from a tangled problem and getting to a point of clarity and zero-tangles.
Kent goes on to describe three phases of company development; Explore, Expand, Extract. (I think he was partially inspired by the 4X game-type if you ask me.) He offers a lot of wisdom for workers and founders here. But to me, the most important take-away is that the skills required in each of those stages are different. Different people enjoy different stages, and are good at different stages.
Working in Extract mode may make perfect sense and be the most natural thing in the world to you. But I am going to start getting a tickle in my throat and my leg is going to start twitching. To me, extract mode feels like there is “Nothing. To. Do. At. All.”
I am most comfortable in Expand mode. I’ve spent most of my career there. I know what to do there. Take what works today, make it break less, make it bigger, better, faster, and shiny-er. I have not been able to accomplish everything I’ve wanted to there—but I have learned a ton about how not to do it.
I am most interested in moving closer to Explore mode. In pushing the envelope on what works today. Figuring out why it works—rather than just accepting that it does in fact work. It may work…or maybe you’re being tricked. Whatever you think, you’re probably wrong. I love being wrong. If you never think you’re wrong it means you can get blindsided at any moment. And that hurts.
Read more: Kent Beck's Sigmoid Curve
There has been a lot of talk about “Manager READMEs”, and I’ve seen a number of folks write their own version of a “what drives me” story. This is my attempt to work it out myself, and write it down.
I am a very simple and principled person. There are many things that I care about. I am learning there are even more things I do not care about. It will take a great deal of energy to make me budge on something I care about. I quickly get out of others’ way so they can do the things they care about.
I write and speak plainly. My wife reminds me that isn’t always the best idea. I value written communication above nearly everything else. Good writing requires taking the time to understand the topic you are trying to communicate. Refusing to write indicates to me that a person has not full understood a thing, and is not willing to defend their choices.
My time is the thing I value most. It is the one thing I cannot fix, grow, or change. I do not want my time wasted. I work very hard not to waste others’ time.
Last night, a good friend helped me make a realization about myself. I fundamentally don't trust people that don't have a fundamental angst about where they put their effort (e.g. their "work"). We'll just call it my "New Yorker Charm" I guess. #HumpDayConfessions #catharsis
— jobelenus.eng🏴 (@EngineerJohnO) March 7, 2019
👉 I am given business context, pointed in a strategic direction (given a valid metric-based goal), and then given tactical autonomy (the authority to act). At this point in my career I have established that I am a capable and responsible builder of systems. I value learning user behaviors from what I build, and I value learning system behaviors from what I build. When I am told “we know our users,” I know I’m being lied to. I find little value in someone making a 20-point plan for me when more than 10 of them will change along the way. And if none of them changed—its because no one was observing the behaviors and learning from what we built.
👉 I see that we are operating near (not necessarily on) the leading edge of our industry. I mean this both technically, and culturally. I am a generalist, and I certainly have my “T-shaped” moments on certain topics. But I do not claim to have the depth of knowledge to be driving the leading edge of world-class work. There are only so many of those people who are alive right now. I am not one of them. When I see my organization purposefully acts in opposition to the direction of either a technical or cultural edge in the industry I will speak up.
👉 Collaboration within my own team, and with other teams is encouraged, expected, and prepared for (peer accountability & teamwork). I get excited when I ask a question and get a response with a reference to a written down answer; whether its a code comment, commit message, saved chat history, or external documentation. It shows me folks know their team interfaces with others, and their software interfaces with others. They had enough empathy to write it all down. Bonus points if multiple people give the same reference—that shows me teammates are on the same page.
👉 I have a deep bias to action. There is little to gain from pure speculation, wondering what the cost-benefit of a particular choice is. There is so much to gain from the concept of “Go and find out.” (shamelessly stolen from “The Toyota Way”). There are so many resources available to us that we can get straight down to testing and experimenting with code services when we have questions.
💥 At this point my career goal isn’t simply to build something someone thinks is “great”, or worth a lot of money. I want to work in an organization where I can grow and build a culture of increasing engineering momentum. Creating team(s) where our work builds on our previous work. Where we are constantly improving both quality and time-to-market. Where we are constantly learning from what we deliver (both learning technically, and learning from our users and customers). I will naturally work “on” the business, as well as “in” the business. If I cannot do that, I won’t feel like I am a member of the team.
Read more: How You Can See Me At My Best