I like to search the results of man, and I love that many command line tools use a man-style document with their help system. My system is using `less` as it’s man pager, and it’s help pager, but ever since I started using oh-my-zhs my screen has been clearing when I <Esc> :q! after finding the answer I wanted, which means I can’t just look at the results and type them into the shell.
I wanted to thank Chris F Caroll for this answer, because it’s exactly the solution to the problem I was having
export MANPAGER='/usr/bin/less -isXF'
-X is your friend for telling less just to keep in the screen
This isn’t a finished essay by any means. It’s an in-progress record of the problem I’m dancing with, and the paradigms I’m cuddling with. But first some history.
At Flextrip (travel startup 2011–2012) we were tiny but already playing around with Chef and Chef clones (Rubber https://github.com/rubber/rubber) as a way of automating our deployments — talk about premature optimization. I also played around with Vagrant as a way of trying to reduce disconnect being Prod and Dev environments during freelance work but the word DevOps never touched my lips.
When I worked on Data Science at SITA (2013) we were a 60 year old Airline owned tech services company that offered mostly enterprise data warehouse appliances for airport operations, reservation systems (still half on TPF mainframes) for Airlines, and Enterprise Service busses for the entire aerospace industry. The data and the traffic were at-scale (petabytes of data and 10 Gbps of throughput of actual messages), the lingua franca was Java and MVC Spring was the hot new thing for a lot of our products. But we were also working on all the new startup inspired open source projects/paradigms like Cassandra, Hazelcast, NOSQL and we were embarking upon development of data streaming, event driven architectures. But ultimately the tooling for data science had not reached the level of ease and maturity it has today. I was using SciRuby, and R to try to build streaming ingestion to feed a Monte Carlo simulation that exported coefficients to a curve fit model estimations of passenger volumes and locations in an airport. MLaaS was still a ways off and we weren’t talking about FaaS or Serverless, and the closest we came to Docker was designing VM deployment architectures.
At HP Travel (2014–2015) the scale was even bigger but we were mostly supporting legacy appliances hosted in a 3rd Party On Prem Data center (emulated mainframe software). Pieces of modern architecture beginning to show up in applications all across the org but these were being designed with the REST/MVC paradigm and very little attention was being paid to the performance, cost and organization efficiencies on offer from Public Cloud vendors. One area where we began to move towards today’s paradigms is by deploying Kafka as messaging system to provide as close to immediately consistent primary/replica architecture as we could for Airline Availability servers (the database that tells selling systems what price levels different products should be sold for to maximize revenue on a flight).
At Airhelp our Architecture choices were almost primarily driven by Devops culture but it was still a major struggle to get everyone on-board with the benefits of docker, docker orchestration tools (like Kubernetes), and serverless / FaaS technologies.
I got so annoyed that I wrote a blog post about it. Recently I realized I had 5 credits on Audible.com and I had to admit that I wasn’t using the service. I’d been here before. 🤦🏼 5 months earlier when trying to cancel I allowed myself to be manipulated into to downloading 5 audio books which remain unlistened.
Apart from the scammy way in which they have ended my subscription on the date of cancellation — as opposed to ending it on the date of my next billing (which makes me feel cheated — even Hulu doesn’t cut your service off when you cancel, you paid for the month, you get the month) — there is a lot to disappoint here.
I would not be surprised if the Product Manager at Amazon who implemented this didn’t come over from or look up to Hulu as inspiration.
Up Next: let’s pretend “I’m just trying to improve my product” while I make it seem like feedback is required to complete the cancellation. Also I need to feed the next step in the recapture funnel.
I have to hand it to Hulu, they actually take care of this in 1 screen not two. They (Hulu) designed the user feedback to explicitly drive the next step in the recapture funnel. No matter which button you press you’re going to have at least 1 more step before you can cancel.
Two For One User Survey Plus Recapture Data I can use to prevent you from Canceling
Given the monthly subscription fee is $15, and I’ve been manipulated into keeping this subscription against my instincts for 10 months, Audible made a cool $150 off of me with just a tiny bit of Coercive UX. That extra income makes this practice really attractive to a product manager or business GM. But it is wrong.
The UX crowd likes to call this practice Dark Patterns, but in an era where every one seems be entitled to their own facts and words have figuratively stopped having any literal meaning in the mouths of public figures, I prefer to name it what it is — coercive.
In my previous blog post I expressed a kind of moral neutrality to the practice. In my previous blog post I expressed a kind of moral neutrality to the practice. That’s not surprising, considering that I, like many of you, make my living trying to convert users. But I’m a fan of being self aware, and I’m aware this is immoral design. It doesn’t mean I won’t continue to use such practices in similar ways myself — but I’m going to try thinking more about my users and caring more about those people than my company’s profits. I get furious when I encounter this stuff and when it happens to people I care about my blood starts to boil. The only way I can imagine a product manager can be okay with this practice is if they are just not engaging in empathy with their customers — who are people. Can you imagine the facial expressions you’d get if you tried this in person, face to face?
For Amazon, a company that in many other ways leads with customer obsession, this is a clear fail.
Customer Obsession. Leaders start with the customer and work backwards.
If you are a product manager at Hulu or Audible and have a solid defense of this practice I’d love to hear it. Just At me on the Twitter. @ashr
My time with Nordstrom was everything I’d hoped it would be.
Late Stage career growth is a personal journey
Last April I had no idea how large the Nordstrom product and engineering teams were, nor how substantial their scale. I had just come from a late stage startup (post-acquisition), and I think I probably expected a significantly less agile culture with a slower cadence of product development, but hoped at least the scale of it would be my opportunity to learn more.
I couldn’t have been more wrong about what I’d find, or what I’d learn. What I found was an engineering org that was very much in transition and full of amazingly passionate, skilled, and compassionate people.
The most important thing I learned was actually an insight into what motivates me. What I learned was that the same things I loved about Airhelp (my last great job) can be found in an organization dealing with 10x the scale.
winning and welcoming
The default mode at Nordstrom was kind. Management books talk about culture coming from the leadership and it was immediately clear that this culture of kindness was not just a company value, it was a family value. The speed of an organization like this shouldn’t look like the speed of a startup. Reacting to pursue uncovered opportunity is still key but when you run at this scale, you are not racing to a finish line, you are running a marathon, every darn day. So you have a lot more meetings, you do a lot more planning, and you do a lot more validation of a choice before it begins to constrain all your options.
Previously I had been very animated about the question of how to do Agile at Scale? How do you achieve the right amount of autonomy to enable rapid iterative development and deployment while simultaneously maintaining alignment across your entire org to make sure that all your investments are being made in the right places at the right time and at the right scale. The simplest way of describing what this looks is to imagine what a non-aligned org looks like.
Imagine marketing has spent an entire quarter’s ad budget in a single week because they’ve unlocked a super effective CPA channel. The entire front end team is at a conference. The operations team is in the middle of migrating their Kubernetes cluster from Microsoft to Pivotal. The SEO (growth team) has just unlocked some amazing SEO juice tripling regular organic traffic. Your site is down and buggy, your quarter’s ad budget is lost, and Google deranks you because of your plumetting conversion rate due to site performance. That’s what a non-aligned team looks like.
We didn’t have any of that at Nordstrom, but there was a higher than expected level of autonomy — and not as much alignment as you might have expected at a 100 year old company. While that autonomy may have been costly in some ways because there was certainly some duplication, and some dead end projects, on the whole the autonomy enabled a culture of helping each other out. The momentum of that company is driven not at the leadership level, it’s driven by the community of technology folks who are being kind and supportive of one another.
There’s a reason they say Culture Eats Strategy. I’ve been working mostly strategy for the past year, and none of my work has had as big of an impact on the future success of the company as the folks who’ve had the opportunity to work on culture. Making the engineering culture more equitable, more welcoming is the reason that Nordstrom is winning.
I’ll be leaving Nordstrom at the end of April and I encourage anyone looking for a wonderful place to work to give them a look.
And if you have a welcoming and winning org and are looking for a technology leader – Or someone to help cut your cloud bill, send me a DM and let’s talk.
I’ve been thinking a lot about how many people, how many tasks, how much effort, how much cost for public cloud managed services you should be allocating as an engineering leader.
There’s this promise that with each layer of increasing abstraction in modern software development we’ll be freeing up ‘developers’ to do more customer value work. It’s hard to argue with the impulse, and the logic makes a lot of sense. But in practice as I think about the evolution of software applications we’ve seen this promise before. I do think each successive wave of innovation is increasingly orienting ‘builders’ towards users, but each layer of abstraction comes with it’s own opportunities and costs.
If I think about how software development practices/architectures have enabled our ability to invest a larger share of our efforts I can propose a split between user value effort vs utility work
how much time & money we spend building the part the user needs for value) versus utility work
vs
how much effort we spend on everything from networking, security, dev tools, test & monitoring, abstract data management code, memory or disk management, etc
Here’s how I think many of us imagine it, or want it to be. We’re driving towards a future where the majority of your efforts are directly related to user experience, improving recommendations, increasing conversions, increasing retention and engagement, and treating all that back-end stuff as commodity.
80% investment in User Features
But if I try to allocate a budget (starting back in the 70s) of an organization at scale, I end up with a very different set of numbers.
80% investment in User Features
34% User Value seems to be some sort of limit, and that may even be naive and optimistic. I’m certain I’ve left out major categories of effort in this list, and it doesn’t even begin to include investment in product designers/managers, project management, or any of the usually distinct and separate departments like marketing and human resources. The problem might simply be one of allocation ambiguity. What is direct effort towards customer value? Data Science and Data Engineering are projected to become the number one job disciplines within the next decade — so shouldn’t I allocated machine learning in the Customer Value bucket? — not to mention there’s a lot of wiggle room in the term ‘development’. The Serverless category represents my best guess of where I think a large organization at scale should be spending it’s ‘effort budget’ if it has the benefits of event driven distributed architectures managed on a hosted pubic cloud.
These aren’t staffing ratio recommendations (salaries vary wildly) or even story point allocations just ‘effort’ in general.
80% investment in User Features
If instead of User Value/ Utility Effort, we try to think of it in terms of User Value versus Hidden Value, and I sum up my effort budgets from above we end up with a much more realistic picture of the shift towards User Value as software architectures and process have evolved since the 70s.
80% investment in User Features
I also tried to think about what I expect from my cloud/vendor costs (your deployed costs) to run all this ‘allocated effort’. I had to add an additional category because just shipping bits around and store backups and other non-operational data is going to generally eat up 2-10% of your total spend as you reach scale. Here is how I came down on what I’d expect from a large organization at scale operating strategically with an event driven micro-services dominant architecture.
80% investment in User Features
Obviously every business is different, and however you bucket your costs you might have a very different take on these allocations, but I’ve been asked so I thought I’d take the time to put it out there. And for back of the enveloper calculations about Monitoring, I’ve consolidated several sub-categories into a single Infra category — nota bene — I’ve lumped cloud costs, vendor costs, APM, auditable transaction logs, and operational infra monitoring under the single category of Monitoring.
80% investment in User Features
So finally, in answer this question
80% investment in User Features
It looks like my back of the enveloper calculation is 6 to 1 ratio for infra versus observing infra spend.
I’ve been laid off three times in my career (not counting the 3 times I’ve laid myself off, when it was what was best for the company), I’ve been the author of 3 layoffs in order to save a company so that those who remained would continue to have good jobs. In total I’ve helped or administered about 8 layoffs.
Nasty business
It is never easy work. It sucks on both sides. Even when you hate your job getting fired is painful, no matter the reason. Firing someone is painful too but at least you have work to return to, so you can compartmentalise.
Being laid off when you are over 35 can be terrifying. “Am I in the wrong career? Have I failed to level up, will my next employer see me as ‘damaged goods’? Am I already past my prime?”
When you know someone who has been laid off, be sure to call them and ask them how they are doing. If ever someone needed a friend it’s during this time.
For the lucky ones who have good jobs
Divorce, family deaths, and job loss are the number one risk factors for dozens of terrible outcomes. If you are privileged enough to be getting job offers every week lend your privilege to someone you know who has been laid off. Take a few minutes of your day to think to yourself — “whom do I know that would love to work with my friend?”
LinkedIn is a great tool for this. An oft overlooked tip: Search your network using the keyword “Hiring.”
Whom do you know that is hiring? You can also post a status update with a link to your friend’s profile page to help get the word out for them. There are dozens of ways to reach out and help.
For the Laid Off
Getting sacked is a drag but it doesn’t have to be traumatic. Lean in, ask for help, don’t be ashamed. Know that you are valued and wanted by dozens of teams nearby. Even if the recruiting algorithms fail to see the whole person in your resume, understand that someone in some team working hard right now needs your help and wants you to join their team. Don’t give in to depression, whatever that may look like for you
Go to meet- ups in your field.
Be shameless in your quest for your next job
Worry not about being desperate.
I have never not hired someone because they were eager to work.
Hiring managers
Heed my words. People get sacked for dozens of reasons beyond their control. Sometimes they had a terrible manager who failed to help them succeed. But usually their role, and by extension they, became unnecessary for reasons beyond their control. A product line was a bad market fit, a programming language was discontinued, or simply because they tried and failed at something. Do not punish unemployed people when examining resumes. The idea that good workers already have jobs is beyond proven to be incorrect. Do yourself a favor, hire the hungriest person you will ever meet, someone who wants and possibly needs the job.
As a developer manager (of sorts), I often find myself digging into code I don’t understand in applications when I’m trying to help out, or more likely when I’m dog-fooding our development processes.
So it’s not surprising that in my first months at Avvo as VP of Engineering I would encounter some code that shocked and horrified me. The reaction can be normal for any experienced developer, and trashing legacy code is a time honored past-time in IRC and now in slack channels. Those developers who were around when the code was written will often chime in. Lord knows most of my own old code would horrify me now.
Especially the OO C++ class hierarchies I created.
But as a manager I made a terrible mistake. I took to slack in our developer channel and asked the big “WTF is this stuff” question. Now the code I was looking at served a purpose and the anti pattern I was looking at was rather stark, but there had been a pattern, and it was intentionally done this way.
I immediately realized my error but there were some developers in the channel who got to see me “open mouth, insert foot” in real time. I quickly set about trying to edit away my comments and ask some actually useful questions instead of code shaming whichever author had written the code. Talk about awkward.
The next day at least one or two developers mentioned that code shaming is an anti-pattern, but a forgivable one.
However, as a manager, it’s never ok. It doesn’t matter if the authors have long since left the company. There’s almost always a good reason code gets written the way it does. It’s almost never because no one cared or because the developers were unskilled, if anything it’s usually due to poor engineering management.
After all, I don’t want my developers writing perfect code, or adhering to idealistic best practices. I want them doing the minimum necessary good code and the maximumpossiblebusinessvalue.
There’s good stuff and bad stuff everywhere and when a manager starts code shaming it can increase everyone’s anxiety.
I’m still learning, but I thought I’d share this mistake, and add it to my short list of management principles:
Shaming people isn’t an effective tool for improving performance, and shaming code doesn’t help your team write better code, it just lets them know you’re an elitist punk.
Be kind and generous and helpful to your teams, don’t code-shame.
In my twenty some odd years of working in collaborative projects I’ve encountered dozens of management theories on productivity and effective models for working. I have always tried to pull from the relevant portions of each process into my work when it brings value to the team I’m working in or leading. Initially I called my process for selecting which pieces of whatever management theory (Earned Value , Scrum, Kanban, Matrix Orgs) => “Whatever Works”.
In time I modified it to to Whatever Works Well (after having hit the shoals hard when some agile metholodies were ported poorly from one organization’s blog post to a new org)
Lately I’ve been thinking about a decision framework I’m calling Whatever Works Well Together. (adding an emphasis on that good old fashioned value of Team Work) These thoughts are hastily offered up without much production for mass consumption. Just some notes, with some proofreading provided by new dev manager team at Avvo.com. We are executing within a Matrix process that emphasizing Journey Teams, and my current thoughts are about how to best work within that framework, leverage its inherent benefits, but do it at scale, and with higher speed.
Think of Whatever Works Well Together as heuristic framework that asks and answers the following 4 questions.
[ ] Did we get it done? [ ] Did we do the right thing? [ ] Is everybody happy? [ ] Could we do better?
We can abstract these to 4 organizational elements, it’s easy to see this as a system of dependencies. A simple circle can illustrate.
Work, Vision, People, Culture
Work is a job. It’s work after all. Often it’s not fun but even when it’s not, it still has to get done. It gets more fun when you have more skill. The better you get at something the more fun it becomes until it doesn’t. Then it gets boring. So you have to increase your challenges so you can increase your skill again and the work becomes fun again
Vision is the why of the what. It’s focusing on current funnel optimization instead of retention oriented features in order to help the company grow. It’s measuring your product and users and using this data to prioritize the highest impact opportunities. With Vision, work becomes meaningful and filled with purpose. The most demoralizing thing in the world is to discover that the hard work and sacrifices that you’ve made have had no impact. Nothing destroys an enterprise more than wasted and fruitless labor. Without vision we are just thrashing around in the dark. In the modern company vision must be accompanied by data and evidence. The whole point of BI and analytics is to be able to measure if the work is delivering to the vision.
People, we’ve all known people that were so skilled at their jobs and had such intuitive instincts that they could deliver amazing products and achieve business successes with no formula or process whatsoever. This can also happen in groups. Small start-ups, 10 to 20 people can achieve amazing things without ever having defined any rules or process to govern their work.
Imagine you hire only rock-stars, can you skip this section now? No. Even the best team effort can be foiled by the misalignment, or the presence of the wrong people in the wrong roles. We can say: When the right people are working on the right things magic happens. Are we done yet? No. If you’re lucky enough to have the best people as individuals, they must function well as a team. If the group isn’t healthy and happy then any investments (adding team members) in development efforts will only slow down the work. Let’s assume you treat your teams well, provide them with career options, and lead them towards meaningful and productive work, can we say we’re done with this yet? No. When healthy, happy, skilled, visionary people do not have enough autonomy — they will perform poorly, and they won’t likely remain happy and healthy for very long
An inclusive, supportive, welcoming, and nurturing workplace that enables and relies upon autonomy, alignment and accountability is essential for the health of a team and the organization as a whole. There are no unhappy players on a team that has just won the championship. If we want to win, people need to be happy, healthy, and motivated to work autonomously in alignment towards a common vision for which we are all accountable. Simple Right?
Culture is just the transmission of values and experience. Culture is the way to institutionalize success (or failure). The work will not always be good or on time, the vision will not always be right and the people will not always be at their best. In order to change, adapt and improve, an organization must have a healthy culture that invites new ideas, encourages lessons to be learned and the organization can adapt. It is culture that completes the circle and allows the work to be executed according to a commonly understood vision with happy productive people who are improving and achieving amazing things.
Notice there is no Process in this circle. I’ve seen this cycle work with absolutely no process. We all have, small teams come together all the time to get the right thing done with happy people repeatedly with no rule book or instructions. Sometimes prescribing a process helps, even surgeons use checklists to ensure they don’t make tragic avoidable mistakes. Process is most useful when there are many competing, interdependent and complicated pieces because it is a formalization of effective communication. When processes work well, every things is working, but when they are too heavy they introduce waste and cost more than they add value.
You might mistakenly use P for process in the circle above, but any organization that intends to scale in a cost efficient and urgent manner needs autonomy and top-down process in the driver seat is a poor alternative to having the right people in the right place working in the right conditions. So if not prescribed process then what?
Effective Communication is always listed when successful organizations describe what worked well for them. While not mutually exclusive (process and communication), ongoing and effective communication is the reason that process works. It is the glue for all other efforts in improvement. It’s a cultural value and it requires effort and discipline to achieve and maintain.
The teams that work well with little process almost always have effective communication. They are aligned In order to
✅ Get it done — Work 👷
✅ Do the right thing — Vision 👁
✅ Make everyone happy — People 😁
✅ Do it better next time — Culture 📲
there must be open and effective communication. To keep doing this loop means transmitting and socializing your experiences and values and requires effective communication.
It’s easy enough to say a company values effective communication, but what does it look like in the wild. I can’t tell you how to achieve it, but I know it when I see it, and it almost always has these three characteristics: Trust, Mutual respect, And a hunger to do better, together
Organization Scalability
A final thought, to scale all of this requires varying measures of autonomy, alignment,accountability in the organization as a whole. Engineering, Product, Marketing, Sales, Data & Analytics, Operations, Human Resources, or any department you may have in your company must all function with a hunger to get the right thing done,with happy productive people who can repeat and improve the process. Sounds easy right? Jusk ask yourself:
