My son recently participated in an All Star tournament for his Little League. Watching him through the tournament, the confidence he built throughout the regular season was clearly abandoned for feelings of alienation and a general lack of passion.
When we feel the pressure of highly capable people around us, it can affect our mindset. We strive to be great in our given discipline yet when we achieve greatness and are subsequently thrust to the stage, we sometimes wither into our former selves.
Every game has an important, elevated “next level” stage like an All Star game in Little League or an executive leadership meeting for a new Director. It’s in these situations that you’ll inevitably notice that some of the players are not shaken by the heightened pressure but instead thrive on it. When others crumble as the game intensifies, these individuals exude a calmness under pressure which, when it becomes contagious enough, can spur on the team’s ability to succeed in spite of their nerves.
What, I wonder, causes some of us to break under pressure versus see the pressure as just another game to be played? Perhaps the only way to build this mindset is to have played those high pressure games enough to not be fazed by them.
Perhaps it’s on the leaders of great teams, then, to practice high pressure situations on the fields of greatness (real or simulated), in order to build comfort and coolness under pressure. If we can do that, maybe our entire team can be All Stars.
When I first started leading software development teams, I was extremely naive about what it meant to be a manager. My father was a small businessman and lead his company and its employees with an unmistakable authority and command-and-control style. I was naturally influenced by this approach early in my career and applied it to some of my first teams. What a disaster! I’ve since learned this and many other lessons about what it means to lead engineers, developers, and product managers in their day-to-day work.
So, here are some opinions on engineering management I think could help the newly promoted.
Let Go, But Stay Current (or, Know Your Strengths)
There is alotofcontent on the subject of whether engineering leads or managers should continue coding, architecting, and being an individual contributor. It’s very tempting for the new manager to believe she can continue to code. After all the source code is right there, still just one git commit -m 'Fixed typo' away from being improved upon. While I think the answer can vary based on the company, the team, and the product, I would argue it’s better to get out of the code for the most part.
I was never a particularly strong developer; often leaving tasks to the last minute, under-scoping work, struggling in the pre-Stack Overflow days to understand harder concepts, and so on. But I did learn that the most effective engineers are commonly on the most effective teams and so I instead began gravitating toward making sure teams around me were healthy. This often meant negotiating time to reduce technical debt (often of my own creation¯\_(ツ)_/¯), upgrading development systems and IDEs, and automating tasks like builds and releases. This became a strength overcoming any weaknesses in my coding ability and I began to take satisfaction in a team’s increased ability to perform without my direct contribution to the code.
So, while I believe the first thing to get right in your new role is to focus on the team’s health, I also believe it’s important to stay current on technology and programming methodologies being deployed by your team. As a manager, you will be asked to break ties all the time (or just shepherd conversations in one direction or another) and it’s best to know a thing or two about the current issues being considered. Don’t be the manager who defers tough decisions by bringing up the good ole’ days when you wrote that CORBA interface that made the company so much money in 2003. It’s irrelevant today and, anyway, your code probably had to be thrown out at some point.
Manage Your Team’s Mindset
Today’s workplace can be a stressful place. We seek to stay productive throughout the day, ever seeking the elusive “flow state.” Meanwhile, a successful software team is often an endless fountain of distraction. The more users adore your software, it seems, the faster and louder are their complaints about a bug you just shipped or how a feature misses the mark. What a catch 22! How can we achieve high levels of productivity when doing so causes more chances to be distracted?!?!?
My strategy: maximize mindfulness. The software team that can consistently drown out distractions, face urgent “fires” without slipping into endless firefighting, and find peace standing in the front of the mountain of work called “the backlog” is the team that has the correct mindset. Fostering a team’s healthy mindset is now a primary job for you as the engineering manager. They cannot do it on their own.
To encourage a healthy mindset on an engineering team:
Assure the team that there is always time to do things correctly, even if it has be a little later than today for the sake of shipping the current solution.
Foster a sense of reasonable compromise and give-and-take, even in the face of seemingly intractable trade-offs resulting from the first point.
Let engineers pick their own tools or build new ones if necessary.
Listen to their needs and observe #allthefeels. Effective engineers will solve problems right up to and including the point of exhaustion, frustration, and even rage. Don’t let it happen.
Coach engineers to strive for high quality on every line of code, but ensure they are comfortable shipping things before perfectionism kicks in.
A healthy mindset in an engineer is a precious gift, freeing up the manager to focus on the company’s goals, customer needs, and recruiting new engineers to the team.
Master The Ability to Connect The Work to the Mission, Vision, and Roadmap
This lesson applies to pretty much every role in a technology company, but the impact to an engineering team is compounded many times over. Specifically, the engineering manager must master connecting the company mission, vision, product strategy, and feature roadmap to his or her team’s day-to-day engineering efforts. When a team doesn’t understand why they’re working on something, it breeds conflict, distraction, busywork, and analysis paralysis.
“We all know that these functions must work together toward a common set of goals that involve a satisfied customer and a money-making product. The roadmap is a critical opportunity — frequently missed — to articulate those goals and rally everyone around them. Before you can establish specific goals, you need a vision, a product vision in particular that guides the direction, not only for the goal setting but also for all activity on the product.”
from Product Roadmapping by Evan Ryan; Michael Connors; Bruce McCarthy; C. Todd Lombardo
Like the crew of a ship in the middle of the ocean, a team constantly looks to the captain to tell them where they’re sailing and why. Like a remote island with the promise of treasure chests full of gold, a finished and successful software project should be something each team member desperately wants to attain. So, the engineering manager has to clarify what is so great about the software to be built, the brilliance of the roadmap, what a feature’s purpose is in the world, and how amazing it will be to finish the project.
There is a lot of overlap here with the Product Manager role, so common in startup technology companies. But I believe the engineering manager has a responsibility to make sure these connections are made whether the PM is succeeding in doing so or not.
Meetings Suck. You Will Now Create Them. So, You Suck. But It’s OK.
Dear New Engineering Manager,
Sorry, but your calendar is now officially f*cked.
Best,
The Gods of Management
Remember the days when you had long, uninterrupted blocks of time to just think about a software problem, design a solution, implement it, write tests first and iterate on the final solution? Yeah, those days are gone. But don’t make the mistake of thinking that your whole team has to suffer your newfound lack of whitespace on your calendar. Their time to dedicate to such things should be high, even as yours dwindles to zero.
For more useful and meaningful insights on this topic, just see Chapter 5 of Managing Humans by Michael Lopp. In fact, just read the whole book.
There are many different lessons that can be learned in the span of a management career, but perhaps the biggest thing to remember is that your new goal is really to build better engineers. By removing impediments like meetings, paying for expensive conferences, and coaching individuals through tough architectural challenges, you are not just helping them build a better software product, but also a better self.
“Management is the opportunity to help people become better people. Practiced that way, it’s a magnificent profession.”
– Clayton Christensen
So, welcome to management and soak in the inevitable fatigue, the constant stress, and, if you’re lucky, the chance to build a team that will do the greatest work of their lives.
Imagine you’ve observed a problem that many people around you experience. Like how, for instance, meaningful home automation is still extremely hard for the everyday home owner to achieve. So, being a smart product manager / programmer / entrepreneur / hacker / designer / innovation-generating-machine, you set out to solve this problem once and for all!
Assume, for a moment, we are going to deploy a software solution to this home automation problem. Some time ago, two major schools of thought emerged for solving software problems:
Big design up front (BDUF) – Deep analysis of the problem, use cases, conditions, acceptance criteria, functional requirements, user interface flows, interaction diagrams, and so on with the ultimate deliverable of a massive, beautiful product requirements document (PRD)
Extreme programming (XP) – Immediately start to develop a solution that kind of solves the problem, but without really knowing why, what, and for whom. Put off any robust architectural designs in favor of highly tested, peer reviewed, and simplified code. The deliverable: working software that did some stuff we were asked to do, with lots of passing unit tests
The BDUF approach leads to massive budgets, expensive research, wasteful over-specification, and bloated software which often doesn’t even meet the real needs, which may never have been discovered. The XP approach suffers from constant churn in the code as requirements begin to shift over time requiring architectural design changes and massive refactors to the implementation and UI design, leaving customers clinging to product roadmaps in the hopes their needs will eventually show up there.
What are we to do? How can we describe the home automation problem we want to solve to our engineers, without massive amounts of analysis paralysis or wasteful hacking together a solution as we go?
Our Savior, the User Story
Enter the user story, the venerated artifact of the Agile Manifesto, Scrum, and all things Silicon Valley circa 2010, where we value responsiveness to change over adherence to a plan, iteration and MVPs over big releases and customer sign-offs, and epic ping pong while enjoying Topo Chico over late nights in server rooms.
As a programmer, I want to drink Topo Chico so that I appear positively bubbly relative to my peers.
A very obvious “agile” user story for our home automation scenario might be:
As a home owner, I want to be able to automatically turn off my lights when I go to bed so that I can avoid spending time turning off a bunch of light switches in every room.
We are hopeful that this short, contextual narrative slices through the process overhead of BDUF and the lack of functional clarity of XP. Business analyst-types, inclined to define the complete set of use cases using the Rational Unified Process (🤢), are instead inclined to write stories that leave off massive functional detail in favor of “let the team decide.” Extreme programmers who just want to build cool shit, must now sit in (gasp) meetings, trying to decipher what the hell words like “automatically” mean and how to scope the level of effort.
But the ambiguity, lack of definition, and risk of misinterpretation in user stories is HUGE. So, we evolved techniques for story estimation, story points regimes (e.g. Fibonacci, primarily), story break downs to reduce scope, reprioritization, refinement, reflection, playbacks and demos, design reviews, stakeholder reviews, customer playbacks, feature toggles, and on and on and on. All in an attempt to simultaneously de-risk building the wrong product and but maintain velocity in delivery.
And still, we build the wrong things, overdue and over budget. All. The. Time.
Milkshakes For Hire
So, along comes Clay Christensen with his ideas about disruptive innovation and customer segmentation around “jobs to be done” (or JTBD). I won’t go into depth on this research here, but if you’re not familiar it is well summarized with the following analogy: a person is not shopping for a 1/2″ drill bit, she is in search of a 1/2″ hole in the wall, the drill bit is merely hired for the job of making the hole (for more see this).
In our history of storytelling to describe software solutions, many now try to apply this type of thinking to agile stories. A popular technique is the job story (explained here), where the focus is shifted away from a persona and more on the trigger of a given scenario giving rise to the need to hire something to do a job.
The JTBD-centered version of our home automation story becomes:
When I am tired and ready to go to bed at night, I want all the lights to go out automatically so I can go to bed without worrying about leaving lights on.
Hmm. Alright. We can identify some of the obvious benefits of this format:
Removes the abstraction of “home owner” which is redundant, irrelevant, and incorrect in some cases (e.g. Airbnb guest)
Describes the trigger for the action of the lights needing to be off (“tired and I go to bed”)
When it occurs (at night)
Less about something an abstract “home owner” wants and is more direct that the lights should just go out automatically
So the way we describe what we should build keeps evolving. Both the structure and context of the “job story” focuses, it would seem, on adherence to a few specific rules for finding product-market fit, including:
If a product is good at meeting a need, then the need can be expressed as a job that the product is hired for
A job to be done emerges when the right conditions occur, which is ultimately more important to specify than the persona to whom it is occurring
Customer motivations, then, are necessarily as much about their need to “hire” something to do a job as it is about their preferences, biases, or membership in a persona like “single female” or “student”, commonly used in the “As a ____” user story template
Finally, to find product-market fit, one should bias toward first understanding the jobs to be done for your hypothetical target market, then aligning a product as the best possible “hire” for that job
Another Possibility: Empathetic Stories
But can’t we go further than just pointing out a user story as relating to a “job” that someone needs done? What if the ideal scenario is that the job to be done never existed in the first place? Christensen’s theory has several flaws in this regard, most obvious being that the solution provider (e.g. the milkshake restaurant in the canonical research example) is constrained to their existing industry.
Maybe we can do better, with empathy. Empathy–defined as the ability to understand and share the feelings of another–might be something we can employ, when specifying product requirements, to better illustrate the purpose of a given solution. I believe an empathetic mindset causes story narratives to abandon the constraints of existing solutions, markets, and industry norms in a very productive way.
So, our empathetic home automation story would go something like this:
Janice, a mother of two young boys, has just finished paying the bills and loading dishes from dinner into the dishwasher. Her husband, Frank, is in bed already, reading a book as he usually does until long after she’s asleep. Time for bed. As she strolls out of the room, Janice leans back toward the kitchen and says, “Good night,” which causes the kitchen, living room, family room, dining and front bathroom lights to immediately go out. The hall bathroom does not go out immediately as it normally would, since Jake, her youngest son, is in there getting a late night drink of water. The hall light remains on for 20 seconds before fading out, just as an exhausted Janice arrives in her bedroom to find Frank reading, as expected, by the light of the beside lamp, which has stayed on. She enters the bathroom, where a light has flicked on automatically, where Janice brushes her teeth, and washes her face before turning out the light and going to bed.
Here, we learn a vast amount more about the scenario we must design and implement into our solution:
The software probably needs to “know” this is Janice, so that the sequence is specific to her. One of her kids telling the house good night two hours earlier should probably not result in the same events unfolding.
A “good night” sequence needs to be programmed to be able to automatically turn off, dim over a time period, and turn on simultaneously
Some lights should not be turned out, even if “all lights” would typically be turned all at once otherwise
We probably should have presence indication in the bathrooms so we don’t turn the light out on anyone
So, you can see the scope of our story has positively exploded, but so has the degree of purpose, clarity, and potential value of the solution. We have a rich and contextual example in which the home automation solution can apply in the real world. Gone is the generic categorization of “home owner,” the myopic specification that lights only go out when saying “good night,” and ambiguous terms like “automatic”.
Perhaps most importantly, this story sounds like the script of a Super Bowl commercial! I would wager that the average salesperson or customer success manager would greatly prefer seeing the empathetic version in a release note over either of the previous stories.
Do we all have the imagination and creative writing skill to specify our products in this manner?
I think we must, if we are to deliver products that we love designing, building, and supporting.
Bob Montgomery was a coworker, friend, and cherished family member to so many of us. But for me, he was also a mentor. He and Janie were responsible for the success of my internship at AMD in the Summer and Fall of 1998 and, as a result, much of my career in software that followed. I don’t think I ever told them what that meant to me. I’ll try now, if it’s worth something.
As I look back on my career over the past 20 years, I’m struck by how much of it was not really a personal choice of mine. Rather, it began with Bob’s decision to bring someone into his work life, to live in his home for six months, and to deliver on a promise to his coworkers that a young business student from CSU Chico could add value to the AMD team. My mentor, it seems, chose me.
Bob came into my life through my wife’s sister, Amanda. In late 1997, Amanda had been working as an usher for the immensely popular Chico Heat baseball team here in Chico. Her skill in serving beers to the premium section caught the eye of the Heat’s closer, Josh Montgomery. One thing led to another and I suddenly had a connection to Advanced Micro Devices (AMD), through Josh’s father Bob. This series of events occurred, as can happen in close-knit families, without me even asking or prodding Bob for an internship. My mother-in-law Lorna probably spoke to Amanda, who asked Janie, who likely mentioned it to Bob and so on. I don’t know the story, because I selfishly never asked. Being twenty-one has it’s downsides.
So, Bob decided that I could use his help and vouched for me at AMD. He decided his input, experience, and guidance was worth passing on to me. What I didn’t know at the time, was that Bob and Janie were to become a huge part of who I am today.
As the summer of 1998 approached, I prepared for an internship at 1 AMD Place, Sunnyvale, CA. Having agreed to take me into their home for an extended six month period, Bob and Janie received me and all of my worldly possessions–predominantly stereo equipment and a gaming computer–to their beautiful home tucked into the forest surrounding Felton, CA. Soon after the Spring semester ended, I began work at AMD.
Fast forward to January. After a busy and stress-filled internship–there was this thing called Y2K that everyone was all freaked out about–I returned to Chico in the Winter to finish up my degree. And in the process, Bob and Janie had become my friends and my family; my Felton Mom and Dad.
I want to thank you, Janie, for all that you did for me. I am so sorry for your loss.
In the short time I was under Bob’s informal mentorship, here are a few things I learned:
How to treat your coworkers with respect and to earn their respect in return
How authority figures are people too and can even be friends, as were so many to Bob at AMD
How to consider, deeply, what others might be thinking as they go through change in a workplace or in life
The value of rising early and exercising (I’m still struggling with this one). You’ve never seen someone improvise in a gym like Bob. 7 reps of bench presses, 23 lunges, some time on the bike…you never knew what to expect!
How walking Labradors along the beach in Santa Cruz can feed your soul
How to make small talk in the car, even during the white-knuckled gauntlet of the Highway 17 morning commute
The difference between drinking alcohol to get drunk–a well-honed skill of mine up to that point–and drinking to complement a meal, smooth out a conversation, and make the stress of the day just a bit less sharp
How to treat your wife, whom I observed he loved more than life itself (still working on this one too, honey)
How to laugh at life
And many more
Recently, I have been working as a mentor with ChicoStart, a local startup incubator, to help energize and grow the tech and entrepreneurial community here in Chico. We talk a lot about what mentors can do to better energize and serve startups in the area. One of the recent efforts has been to formalize what makes a healthy mentor/mentee relationship; how does an entrepreneur choose a mentor and so on. This is a challenging topic for us, as we witness promising young minds making the same mistakes we made years ago. Lately, though, I have been thinking: I just need to be more like Bob. To just give and expect nothing in return. To listen, thoughtfully. To help others consider the weight of their decisions and actions. Bob was so effortlessly good at this.
I hope Bob knew, through the years, that my later career progress could all be traced back to these lessons he passed on to me in those six months in Felton. I believe now, in hindsight, that they are my secret weapons.
He was for me, then, the mentor and friend I didn’t know I needed, but without whom I would not be who I am today. I feel lucky to have known him and will miss him greatly.
For many of us in software of a certain age, making changes to and releasing software has traditionally been a perilous activity. Customers had to be hand-held, release sequences carefully orchestrated, and contingencies planned in case of failure. And so, the best releases were done by the best release engineers (remember that title?)–typically release engineers who were most averse to risk. Thankfully, we now know there’s a better way.
The world’s most effective release engineer. Photo by Alex Knight on Unsplash
Software today is now ideally deployed into cloud-based infrastructures, with little or no customer involvement, with no risk of downtime, and–most critically–completely automated. The risk of breakage is minimized as the duration of Agile iterations dwindles to zero, ensuring that when breakages occur, they can be mitigated in minutes. What was once a massively delicate and stress-filled activity, can be automated into oblivion and reduced to an afterthought. This is the realm of continuous deployment and delivery and it is outstanding.
As teams I’ve worked with over the years have taught me, there are some key considerations in ensuring that continuous delivery is achievable, while maintaining everyone’s sanity.
Careful Code Review
Changes made to the code have always needed peer review. But in an environment where, once a changed has the approval of peers and quality assurance, it is immediately shipped off to the customer, the importance of thorough code review increases dramatically. This is not to say that perfection is the goal (an all too common aim of naive, less experienced programmers), but rather that every change is evaluated for it’s quality and thoroughness relative to it’s potential for negative impact on the application.
Release in the Middle of the Day
If you are waiting until off-hours to release your code, it’s probably a sign that your deployment process is fragile and not correctly mitigating the risk of downtime. Fear that you will break the application at peak usage breeds an overall fear of any change, much less a complex and innovative one. This, of course, has exceptions and is subject to the idiosyncrasies of your industry, product, and customer needs. But as a general rule, the best time to release software is when everyone is ready to monitor and turn around any fixes.
Of course, there are ways to avoid the impact of breakages during peak usage altogether, such as rolling updates, Green/Blue deployments, canary releases, and even very new approaches like Houston.
This is not an uncontroversial subject so flexibility on execution here is necessary. Go with what the team is comfortable with, but also make decisions that build confidence in automated releases at any time of the day.
How Fast Can You Fix Your Mistakes
When continuously releasing software to production, there is an increased need to be alerted, automatically, when an issue has occurred. The human rigor typically applied to big-bang releases–such as manual canary testing, full regression test, and so on–may not be possible given the frequency of releases. As such, when a breakage does occur, it’s critical to have a systematic approach for detecting and redeploying changes (or rolling back, as last resort).
A common model for managing security incidents applies to continuous delivery, as well. This graphic illustrates a few key KPIs that should be kept in mind.
While this graphic is intended to describe responding to security incidents, I like to imagine the same metrics apply when the incident in question is a planned release of your software that goes wrong. By managing the time to detect a problem independently from the time to recovery, a team ensures the most effective reaction times in the case of a failed release.
Stop Penalizing Failure
It is not a matter of if, but when, a software release will go wrong. How the team reacts to this failure is a good indication of whether or not they are ready for continuous deployment. In my professional past, I have been very negative and punitive in my feedback when projects are not successfully deployed. Healthier cultures and mentorship have shown me that a team that can calmly and quickly correct problems on their own is much more desirable.
“If you want something new, you have to stop doing something old”
― Peter F. Drucker
Infrastructure as Code == 🔥
When your entire application can be reasoned about, there is a sense that the risk of any given code change can be more easily reasoned about as well. For instance, if the configuration of an application clearly denotes that a production Web server cluster is set to deploy as a “rolling update” with a minimum of six instances, then the deployment team knows what to expect as the rollout proceeds.
Continuously integrating, testing, and releasing your application to customers is exhilarating and liberating, as long as you manage the risks of something going wrong. If you can identify and eliminate or minimize these risks, the benefits to your developers and ops people are massive.
So go forth and deploy things! Or, more accurately, build robots to deploy things.
When was the last time you worked by yourself for any serious length of time? As one of the perks at my current employer, engineering and product teams are encouraged to work from home on Tuesdays. For me it’s the best way to re-energize after the “collaboration fatigue” of a typical week.
Yet, alone, there is nothing directing your tasks or conversation (and thus your mind). Nothing which is not in your direct control. If you started the day with a goal to achieve (congrats to you!), then you are only reason it didn’t get done. This is both empowering and daunting, as many of us feel the weight of distractions throughout the day as a minute-by-minute threat to our productivity. But to work from home, alone, is to say to the world: “On this day, it’s on me to be effective and, damn it, at least give myself a chance!”
Taking the time to work alone brings clarity to things easily deferred in the maelstrom of the modern day workplace. Haven’t cleaned up your product roadmap? Need to file some expenses ahead of a deadline? These are the non-critical tasks that pile up throughout the course of a week, so easily abandoned as the invasive “open office” brings new issues to light at a lightning pace.
It’s not that we don’t love our coworkers or care about their issues. We even enjoy the office dogs (Captain Crunch and Amelia)! Each interaction at the office cements our commitment to each other, the mission of the company, and the idea that we are a work family. But just as spending too much time with one’s family can create anxiety, so too can an extended period of time with your work brethren. It becomes impossible, at times, to relax enough to just bare down and do the work.
“Your ability to generate power is directly proportional to your ability to relax.”
– David Allen
So, here are a few things I make sure to do when working alone…
Take Regular Breaks
I find it’s critical to stop working at regular intervals and get my head out of the work. I’ll take a stroll around the block, pace around the house, or stretch my back for a few minutes. Anything that relieves the mental pressure of staying focused for too long without coming up for air (as would happen naturally in an office setting).
Do Your Best Work
Save the work of highest value for your time alone. Since at the office there is such a high likelihood that you will be disrupted, the critical work requiring high levels of focus should be diverted to alone time. Focused time to work is a gift and should only be spent on things worth the dedicated effort.
Plan the Day
Don’t let a quiet, distraction-free work environment go to waste by not starting the day with a plan (or making the plan the first part of your day). This is something I absolutely struggle with, as I tend to just dig in first thing. But on a day of prescribed enhanced effectiveness, I believe it’s best to have a plan of attack.
Enjoy It While it Lasts
Focus is fleeting. The common reaction to having a long period of uninterrupted time, I’ve noticed, is to actually fritter it away doing low value work. Knowledge workers, I believe, have become imprinted with the behavior of the busy workplace, letting their minds become distracted and then later hating themselves for it! We should relieve ourselves of the idea of the “perfect” work day and just enjoy the productive time we have.
So, take a break. Go home, to a coffee shop, or to a quiet park and get comfortable with silence as it pushes you to begin closing loops in your mind. Be mindful of the fact that you are in charge of the day, that there is nothing you should allow to distract the day’s effort.
