Saturday, May 29, 2021

What Should Go Into a CMDB

 

It’s not every day that information technology work leads you into philosophy, but designing a configuration management database will do it. Spend a little while thinking about what is known or even knowable about the services you’re trying to provide, maybe you’ll end up asking “what does existence even mean?” Fear not, there are some practical guiding principles to follow. 

First, some background: what is the purpose of a Configuration Management Data Base (CMDB)? Why are we even trying to align Configuration Items (CIs) to the Services that they provide? The intention is to provide visibility into what affects what. The purpose of that visibility is to ensure reliability of changes, by understanding what is affected and planning in advance to minimize service interruption.

Of course, that goal is not simple to achieve. If it were really simple, it would just be a notebook or a spreadsheet, right? But the modern organization has a complex web of interdependent systems. A flat sheet of items misses so much of reality that it fails to make life any easier. On the other end of the complexity spectrum, there’s a very careful and intentional attempt to describe everything important. Let’s pretend that’s possible for a moment, which I doubt… it’s still unlikely that your organization can do it at a justifiable cost. If the system fails to provide return on investment, then it’s scrapped with good reason.

So, the CMDB should only track what is truly necessary to affordably meet the goal of visibility driving change safety. Common advice is to begin with a map of CIs to service offerings. But, is that a detailed 1:1 map? Sort of, maybe. That’s a fine directional goal, but you should not insist on or try to attain a complete CI to service offering mapping on day one. You might start off asking “which service offering does this CI map to in the service catalog”, but it’s all too easy to wander into epistemology. Business leaders are asking for things that can’t be easily made visible and so you end up doing service mappings by proxy… which doesn’t work. 

If you can’t draw a clear line from “this attribute on this entity maps to that attribute on that entity to support this metric indicating that service”, then it’s dreams going into the system, not measurements. So only put in things in that you have to because it’s obvious that they work to support a service. For instance, let’s say we’re talking about a job processing farm. The NAS volumes support the VMs that perform the jobs that test the designs. You can say “this volume supports that job” clearly, but you will struggle to say “this NAS failure is costing that business unit an on-time delivery of that deal” because you don’t have sufficient context in your software. In an organization with sufficient complexity to be considering a CMDB, the business map isn’t clear and the technology map is only a little better. 

What is a CI anyway, and how are you going to identify it? Is a group of ephemeral containers providing services worth a CI each, or one for the service, or none? If you’ve got a big expensive server and you replace its motherboard so the serials and MACs change, do you update all your records? What if you just changed its hostname? Does it still support the same services that it used to? How do you reference the systems you run on a cloud Infrastructure as a Service (IaaS)? Do you need a CI for each of the Software as a Service (SaaS) functions that you use?

The simplest answer to those questions is to manually define and track systems, ignoring identifying attributes like serials and MACs. However, this leaves recalls, warranty tracking, and depreciation out of the CMDB and in another tool, reducing the cost justification for the CMDB. Maybe that works for your organization, but it’s a decision that has got to be done across the organization so that you can present meaningful numbers in your KPIs and compliance audits.

What types of devices should go into the database? Does a network switch count, since it’s critical for making your organization’s software service operate? How about the AC power or HVAC systems that are critical for keeping the switch work? How about the roof that keeps the rain off the switch? Again, the philosophy of everything being interconnected is fascinating but you’ve got a job to do. So, a CI is any item that you can actively manage. I take an absolutist approach here: if there is not a software tool providing visibility and control to the device, then it is not a CI worth tracking.

My advice is to draw a CI line at the management interface. Only put a thing into the data system if it has an agent on it or an interface that enables a management system that you own to collect data. Again, three quarters of my career is in those agents, so call it self-serving if you like. But if the device can’t update your systems on its own; then someone has a job to maintain the “time-saving” tool. If you can afford to allocate people to maintaining data cleanliness in a CMDB so ITAM reports make sense and ITSM service requests go smoothly, that’s great, but it sounds like questionable use of resources at any scale. As Corey Quinn writes, “What people lose sight of is that infrastructure, in almost every case, costs less than payroll.”

Next, treat every collected attribute like it’s a personal insult. For every report, ask how little can you possibly collect and still solve the problem. Is there already data collected that will work? This is the land of practically unbounded high velocity data sets, and scale is going to be a problem. Habits built with a small number of entities will fall apart quickly as your organization grows. 

So that’s CIs… now for the services that they provide. Definitionally, a service offering is something your stakeholders and customers can directly use. But, remember that the point of the CMDB is to de-risk changes, meaning you have to map things that might get changed to that service. Service: Our self-hosted website is up. CIs to provide that: dozens of servers, plus all sorts of unknowables like network and power and HVAC and a functioning civil society. That said, while a one-to-many service:CI map is more complex, it’s the only model that is at all realistic. Business users requesting changes and reporting problems should have no need to select CIs and suggest solutions, so the complexity of looking down the tree from service offering shouldn’t matter. IT operators requesting changes and reporting problems do need to see what those changes affect, and looking up the tree to affected services is theoretically useful. However, those two statements rely on an accurate service:CI map, and that accuracy is sorely lacking. More likely, the business requestor is aware of problematic CIs because they’ve been troubleshooting the problem on their own, and the IT operator is not aware of affected services because the CI has been multi-tasked or repurposed. Therefore, incident triage and handling often include preliminary discovery of the functional map, if possible.

Exceptions to that grim state of affairs can exist: just as I recommend the definition of a CI is limited to an automatically discoverable entity, I also recommend that the definition of a service is limited to machine readable labels. Tagging or labeling CIs with the services that they support allows the CI data collection mechanism to be used to support CI to service mapping. Better, this allows an organization to begin with manual process (apply this label to anything you spin up with this account in these availability zones) and then grow to automation (if spinning up from this image and running this process, then include that label). That way the organization does not have to begin with perfect in order to get somewhat better.

VMBlog Post on Decentralization

 linking to this piece I wrote for VMblog 

Why Decentralized Work Calls for Decentralized Data

Sunday, May 9, 2021

Planning your Year

The plan is maybe accurate, but probably not. The act of planning is a useful time to step back, evaluate strategic position and rethink investment. Using financial targets is a mechanism. If target is thirty percent growth, does the product org have a realistic answer for how that will happen? If that answer is couched in details like “in eleven months we’ll ship the grand frobulator version 2.13.32.005”, then it’s maybe not so realistic. 

For a non-SaaS software offering it takes a quarter for product changes to affect sales numbers, and a year to know if you’re going to get renewals or just have a flash in the pan. It takes a quarter to deliver a change to an existing product. So if you have to make product changes to affect this year’s numbers and you’re just planning them now, you’ve got all your eggs in Q4. It’s key to realize that product time scales are very different from sales time scales. And if your team isn’t already big enough to deliver the features, you’re even worse off because hiring and developing engineers is even slower than making features.

Whatever plan you offer for making product in the second half of this year is setting up for next year’s sales. Why can’t you just parallelize those efforts? Well, customers are rightly suspicious of features that are planned but not shipped. The world of enterprise software sales is also still relatively small and interconnected, so your own team cares about their reputations. They won’t be happy selling sizzle unachievably ahead of steak.

Software as a Service doesn’t change those dynamics as much as people might assume that it does, but it does help to smooth out a spiky cash flow. Whether you’re selling term or perm, on-prem or as a service, trying to move your current revenue numbers with expected product features is very prone to forecast failure.

Using a Technical Edge in Products

"Don't worry about people stealing an idea. If it's original, you will have to ram it down their throats." -- Howard Aiken

Innovative technologies are different than what came before. Product buying patterns are based on what has come before. If you have an innovative technology you will need to bend your customer’s stated needs and your technology’s capabilities to fit each other. Product market fit is not easy or pretty.

“But wait,” you might be thinking, “isn’t listening to the customer’s need the most important thing in product management?” Well, sort of. It’s not listening to what the customer says they need, it’s listening to what they need. The customer’s stated need is shaped by several components:

  • Their actual need to do something, such as pass a compliance audit or roll out a new service
  • Their experiences with other products that they’ve used for this purpose in the past
  • Their team’s appetite for innovation versus surety
  • Their purchasing process.

That last one is extra challenging; if your product fits into the buyer’s signing authority, then great, but if you’ve got to make it through an RFP-gated procurement office, your innovative product is going to be checklist compared with the last twenty years of status quo. The only way through is for your buyer to spend their political capital and force the issue.

If your innovative technology can help the customer solve their real need to do something faster and cheaper than legacy technology, then lean into that and give your buyer the weapons they need. You can get past experience and conservatism and even a purchasing department if you’re really helping the customer save money and time.

I’ll spare the full list of examples, but there are many; trust me that technologies now considered boring infrastructure, such as gratuitous ARP NIC teaming, were once radical and difficult to sell.

Two Types of Questioning


 Answers to questions can easily fit into two flavors: operationalized and free-form. Classify the use cases: there’s the questions you know how to ask, and the questions you don’t know to ask yet.

A question that you know how to ask is operationalized. You’re looking for yes, no, or broken, or perhaps a count. The operational nature of the question means you can improve operations of your system by using the questions. 

You may need to use a series of operationalized questions to drill down to success.

* A good operationalized pattern uses multiple questions to reduce the target set at each step: “are there systems with problems?” -> “there are systems with problems” -> “Show me the systems with the problems” -> “here are the types of problems on the systems with the problems” -> click “Show me the ones with the problem I know how to fix” -> “here are the systems with that problem” -> “deploy a fix for that problem”. This is good because it’s efficient: each step is small, and each step is hitting fewer targets. Whether your problem domain is management, computation, or surveying humans, you'll use fewer resources if you ask fewer questions of fewer targets.

* A bad operationalized pattern == “give me all the data and i’ll search for answers in it”. This is misuse of an effective tool: search through raw data is powerful for discovering what you don’t know to ask, but it can be the wrong tool for daily repetition tasks. It works, but it costs more time and money than necessary.

Noted, it is possible to take the progressive questions pattern entirely too far, as is shown by Microsoft “click to see more” Teams. A forced wizard flow where it isn’t necessary is an anti-pattern. Progressive disclosure of necessary data can become an anti-pattern.

A question that you don’t know how to ask is free-form. You’re looking for weirdness, patterns, outliers, intuition. Is there an anomalous behavior pattern on a subset of systems? That’s hard to answer without a big data lake and a Stats101 textbook, so you stream data at the lake and see what kind of stuff can be found. Algorithms can help, but you’ll also certainly need human analysts. And the findings from that data lake, you will probably want to convert to operationalized questions.

This is a lifecycle of discovery, a process of learning. Operationalized questions grow stale over time, and need to be replaced. Part of the job as an analyst is to maintain the tools.

The Mystical Art of Getting New Things Done

The process isn’t actually mystical: it’s selling an idea to everyone who must work together to execute it. People who would use it. People who will fund it. People who will build it. People who will sell it. Eventually, people who will buy it.

Tell people what you want to do. Lots of people. Product people, engineering people, sales, marketing, finance. Whoever will listen. Even if they're not helping you move the ball forward, they're helping you practice and learn. Explain why it needs to be done, how it will work, what will indicate that it’s working, and who would need to do it. Use a written artifact (document or slide deck) to summarize what you’ve been saying.

Answer their questions. If they ask things you can’t answer, get back to them when you can in writing, and update your written artifact.

Ask everyone you talk to who else you should talk to. Keep going until you’ve got resources. Keep going until they build the right thing. Keep going until customers use it. Keep going until the goals are met.

So far so good, right? Except, that is the process for people who’ve already got the expectation that they drive new ideas to executed success. Product leaders. Maybe that's a product manager in your organization, or an engineering manager, or a service owner. If that isn’t your role, then you’re also adding a second sales job.

First, you need to understand what you want. Are you asking to have the job of executing your idea? Or are you asking someone else to execute on your idea?

If you want the job, it’s actually much simpler to proceed. You’re explaining why you are the right person to make this happen. Details of how to proceed will depend on your organization. Do you have to get the role before you can act the part? Then you need to interview for the role. Does your organization reward acting outside of your lane? Then you need to make sure everyone involved sees that you’re doing so, acting as an unpaid product manager (presumably without abandoning the responsibilities you are paid for). Regardless of the mechanics, you’re effectively campaigning for a job as a product leader so you need to do what is necessary in your organization to get that job along with execution of your idea.

If you don’t want that for your career, then you are seeking a product leader to own your idea. Again, a second thread from driving the idea to execution. Thing is, few product leaders are sitting around bereft of ideas and trying to figure out what to have the engineers build. So, why should your idea be what gets done now? Another challenge you’re going to need to consider is ownership. Are you truly ready to give up ownership of your idea, or do you want to retain some stake? Can you find an accommodation with your product leader partner?

Friday, April 23, 2021

Data Value and Volume are Inversely Proportional

In 2006, Clive Humby coined the phrase “Data is the new oil”. This is often misinterpreted as “Data powers the economy”, particularly by folks who sell data processing and storage, but it’s useful to see what someone who actually uses data says. In 2013 Michael Palmer, of the Association of National Advertisers, expanded on Humby’s quote: “Data is just like crude. It’s valuable, but if unrefined it cannot really be used. It has to be changed into gas, plastic, chemicals, etc to create a valuable entity that drives profitable activity; so must data be broken down, analysed for it to have value." 

Much like refined oil (or processed ore for that matter), the volume of material is reduced as the value is increased. This concept should be intuitive to anyone who’s ever manually sifted a pile of data into a thin report, but it’s sometimes lost in contexts where locating a needle in the haystack is the analyst’s goal. Adding human effort reduces volume.

Corollary: if the project requires massive amounts of data storage, it might be worth asking how much value is going to be in there? Is the purpose to store as cheaply as possible and rarely retrieve? Or maybe the plan is to figure out value later

There’s an interesting confluence of partially aligned incentives between people who have to retain large amounts of data, people who want to retain and access large amounts of data for analytics, and people who just want answers to problems today. “Storage and compute are practically free”, which is why Amazon Web Services is worth 1.5 trillion USD in 2021. If you don't have to pay the bills, collecting raw data for real time analytics sounds great. Otherwise, you'll need to consider this project's needs for data modeling.

A Simplistic View of Venture Capital


I have a lot of conversations with people. 1:1’s, interviews, &c. When the opportunity arises, sometimes those who’ve done startups will talk about their experiences.

There’s sometimes a flag in those conversations about startups that raises my hackles. It’s a description of the money raised as if that were a success metric. “I was at blah”, or “I founded a thing called foo”, and “we raised dollars!” 

I think it’s from accepting the Venture Capital narrative as presented on Shark Tank: that businesses are competing for the pool of dollars, and that the VC’s are judges of innovation. I also think that is a false and self-serving narrative. 

Venture capitalists are salespeople. They are selling a financial product, basically a fancy mortgage. You give away future equity in your house or company for upfront cash today. Good on you, salespeople who can make buying your product seem like a competitive win. 

It is true that have to do your homework in order to get VC investment, and it's more work than a mortgage: a business plan that discusses how you are going to financially swing your journey to product market fit. You also can’t get a mortgage if you don’t fill in a bunch of paperwork with indications on how you’ll pay it back.

The problem with this analogy is that you don’t have to convince a bank that your idea for buying a house is both excitingly novel and fairly safe, you just have to fit the expected cultural and financial parameters. On second thought, given the history of redlining, the analogy between mortgages and venture capital seems pretty solid.

Evidence of purchasing a product is not a symbol of success or status, it is a symbol of in-group membership plus basic competence. 

Back to the interview context, use of this trope is a yellow flag that the candidate may have trouble recognizing or accepting that a thing hasn’t worked. If they can’t point at anything more positive than raising money, their business failed. So they’re spinning a story at me, nothing wrong with that. But I need to see an indication that they can launch a product, so I’m going to keep asking questions.

Product Tempo versus Deal Tempo



Going from sales engineering to product management  was a jarring transition at first, because it represented a change in tempo. As a sales engineer, I lived by the fiscal quarter. While a given customer might be a multi-quarter job to convert, my sales partners and I had money to make and were judged on a quarterly basis. Our bread and butter was the quarterly cycle of identifying opportunities and closing them. I wrote software to help my customers and learned some lessons that way, but the jump to product management in enterprise development organizations still surprised me.  

Shock number one: resourcing. From the field, you can see numbers like the allocation of headcount to engineering, and you can easily imagine that there are dozens of people working on a product. From the factory, you’re more aware that a team of dozens is rare, and a given product probably has one to six actual humans working on it — if you’re lucky. A platform company can do an amazing amount of value creation with small teams, but they can't do everything.

Shock number two: here comes the flood. All products have an incoming stream of tickets. Customers and partners have support requests, bug reports, and feature enhancement asks. Maybe it’s a small trickle, but if the product is successful, there’s at least dozens a day, maybe hundreds. You can try to offload it on someone else, but rigorous process is the only effective answer in my opinion. As a field engineer it can seem that a good idea is its own justification. As a PM, that good idea is only a starting point.

Shock number three: tempo. As the title of this post indicates, product time scales are very different from sales time scales. As a field engineer making free software development feels fast. You write some stuff, it works in your lab, you post it for some friendly users, iteration chugs along as fast as you can go. As an R&D scrum team the process is much slower. You have more platforms to support. You can't rely on some software licenses. You have to think about adversarial use cases and product security. You have to coordinate your activity with the rest of your team in order to build sustainable and supportable software. Bug fixes can go pretty quick, but as a rule of thumb, adding a meaningful feature takes a quarter. Adding a minor feature takes at least a month.

Here’s some advice for sales engineers and similar field characters — of course you’ve probably heard it before, summarized as “Sell what’s on the truck.”

  • If you’re expecting a product change to save your deal you’re making an account management mistake. “Sell the sizzle not the steak” is about making your product look good, not about building a deal on dreams.
  • Shipping product is for dinner, roadmaps are for dessert. The roadmap’s function is to demonstrate that the company is still investing in this product, not to establish a schedule of future feature deliveries.
  • Those said, there is a counterpoint: If you don’t sell it, it will never be fixed. Selling the products is essential to the success of a software company, and if customers don’t use the products then they won’t sell very well. Without sales there’s no one validating features work, no one finding problems, and no reason to fix what’s already known to be suboptimal. So you’ve got to have faith that what the factory says will work can be made to work. 

Followed by advice for product managers coming from the field, which you may have heard as Eisenhower’s quote: "In preparing for battle I have always found that plans are useless, but planning is indispensable."

  • Your tempo has changed, not your activity. Where you were preparing a customer to buy or renew a product (quarterly tempo), you are now preparing the company to invest or maintain investment in that product (yearly tempo).
  • Your scale has changed, not your motivation. Where you were helping a customer to use the product successfully, you’re now helping all customers. Where you were helping a friend with their deal, you’re now enabling the entire field to position your product correctly. Where you were convincing a product leader to prioritize a bug fix, you’re now convincing an engineering leader to allocate person hours.
  • The future is an unknown country. There are only three time buckets that matter. The present has what you’ve recently shipped and the things that engineers are working on now. There is a good chance it will work. There is what you want to do next, which you’re currently designing with your engineering counterparts. There’s a 50/50 chance this will eventually ship. Everything else is in the backlog and does not matter. You can draw a pretty picture of a roadmap with releases for that stuff, but it’s fiction. Its purpose is to build excitement and set up resourcing for next year.

Summarizing, watch out for this offset in tempos, because it can cause inaccurate expectations.

  • It takes a quarter for enterprise software product changes to affect sales numbers, because smart field people won’t sell it until it exists. 
  • It takes a quarter to deliver a change to an existing product because teams of engineers have to build sustainably. So if you have to make product changes with existing engineer allocations to affect this year’s numbers and you’re just planning them at the end of Q1,  you’re going to deliver them in Q3 and you’ve got all your eggs in Q4. 
  • Whatever plan you offer for making new product without allocated engineers is setting up for next year’s sales at best, assuming you convince leadership to rob an existing product or hire new engineers starting now.
  • SaaS doesn’t change those dynamics as much as people might assume that it does, but it does help to smooth out a spiky cash flow.
  • Acquiring a company instead of building software provides a faster bump to your sales numbers because you can just claim the new company’s numbers as part of your own; but it also hurts your ability to deliver software later on.

Sunday, March 7, 2021

What does a Director of Product Management do?



I’ve written up some thoughts for the regular work of product managers and product management interns, but have not yet written about the next level up. What’s day to day like when you’re not just helping one team? What makes a director level product manager?

Just like the definition of what a Product Manager even does, the definition of Director level work is different in different organizations. The easiest way to define the role across companies is by blast radius. A product manager can bring more benefit or do more damage than a developer or salesperson. A product moving in the wrong direction takes months or quarters to discover and quarters to years to fix. A director of PM might be driving multiple products, or driving a new business line, or pivoting the company. In other words, their efforts take that blast radius observation up a few notches. So, what do they do?

First: research the market, build strategy, and make plans. What do you think the path to improved product market fit is? Where do you think the biggest missed opportunity is? How good is the data backing these opinions? How many iterative steps can the work be broken into?  What are the indicators of success or failure at each step? How much investment will your plan take? How are you going to make money with it? This work is mainly done in an iterative set of documents and spreadsheets, with regular output of presentations and backing spreadsheets.

Meanwhile, find a consensus. Who needs to be convinced to support this plan? What would convince them? Can you drive a disagree-and-commit if they aren’t convinced, or do you need to adjust your strategy? This work is done in non-stop meetings, one-and-one and small groups, interleaved with pitches to interested customers, analysts, and leaders. Also you’ll need to make regular excitement-building presentations to larger groups. 

As soon as that process has kicked off, you’ll also need to deal with salespeople selling your idea ahead of its existence. This is a great opportunity to prove the hypothesis of your strategy; if it doesn’t resonate, you don’t have any customers to talk to. If it does, you’re fighting to hold sales teams back from the revenue recognition cliff they’re trying to race over. 

Directors of PM don’t have to do people lead work, but it’s not uncommon either. So you may also be managing team: helping with communication, escalations, training, expenses, PTO approval, hiring, performance management, firing. Oh and of course, filling any gaps in that roster either by doing the work yourself, finding someone to do it, or finding a way it can be left undone.

That brings us to the last duty: saying “no” even more than you did before. As a Director of PM, you’ll start to receive the product ideas and complaints for everything even vaguely related to your domain. The problem is, most of those ideas aren’t well-formed enough to work on and even the good ones go onto a slush pile. The capacity of a scrum team is far lower than most people expect, and they’re probably already staring at a backlog that would keep them busy for the next five years if they did it all. Having influence over more teams doesn't change this reality. On a product feature level, the individual product manager kills ideas, but as a director you’re their rubber ducky, tie-breaker, and bad cop. You are also doing the same thing at a product line or business unit level. You may also need to put your own ideas and projects on ice to make room for new inbounds.

To sum up, the communication and coordination needs go up and the amount of detail work goes down but doesn’t go away.

Tuesday, March 2, 2021

Why I Don’t Like the Squad Model

Development teams have a fondness for trying new models… for better or for worse. I’m not a fan of the current excitement around the squad model. 

What is it

Spotify is the purest example, but the model owes a deal to Stanley McChrystal’s Team of Teams, as well as a bit of LeSS. The basic idea is that teams are tightly aligned to their team mates, but loosely coupled to their projects. Teams will then shift to where work is needed, motivated to do the right thing by their shared purpose and awareness of shared strategic goals. Add a sprinkle of LeSS or tribes alignment for legibility, and you’ve got a model for change from “machine-like” structures to “organism-like” ones. 

Why is it attractive

“Work expands so as to fill the time available for its completion” - Parkinson’s Law. Consequently there is no actively growing development team that feels they have enough resources to do everything they want. Of course, not all development teams are actively growing, and so some teams may have less pressure on this axis. Nevertheless there are lots of teams that can’t allocate sufficient resources to the things they want to get done. 

When you can’t allocate resources to everything you want to do, you’ve naturally got some projects that aren’t getting done. Maybe there are products that need working on, or maybe you have features that can’t be completed or bugs that can’t be fixed. Maybe they’re process requirements like content production, quality assurance, documentation or tech debt reduction. Whatever it is, it’s something painful. If it isn’t painful, it wouldn’t matter, but it's a safe bet there's enough pain to justify considering a big change.

Here are your options. 

  • Option 0: do nothing. You may continue to do without the missing projects, but obviously that’s really painful and no one is excited by it. Something must be done, right?
  • Option 1: incrementalism. You can also try to get the project done with your existing team. You announce that Everyone’s responsible for the project, or you encourage weekend warrior efforts. Or maybe you defer work on all the other projects, with varying degrees of formality.
  • Option 2: radical change. You increase resources so you can resolve the problem. There’s lots of tools in that box, but none of them are very cheap. More hiring, consultants, acquisitions, or try to talk your user and partner community into doing it. Nothing in this list is guaranteed or fast.

The squad model makes it look like your organization is rationally choosing Option 1. It’s not really robbing Peter to pay Paul, there are text books and TED Talks. Kidding aside, there are some legitimate benefits to the model.

The genuinely positive aspects

  • It reduces the effect of Conway’s Law. Teams are no longer as focused on their product, they're more focused on their role in the company's success.
  • It allows for high team cohesion within the squad by encouraging cultural bonds, presuming that the company's culture is sufficiently supportive
  • A nice corollary of that: it doesn’t tie a development team to the market failures of the product they work on. It can suck to see a development team beaten down over failures they can’t control. In a squad model, the team can be judged on something other than eventual product market fit, and may move on to another project.

The mildly pernicious aspect

That movement between projects may sound familiar to anyone who’s ever worked in a professional services shop. Pro services team members go to where the jobs are, and they don’t work on many things that don’t have revenue attached. Bench work and research projects are sometimes an option, but not too much of either. In an enterprise software company, this model leads to a terrible challenge: products have been sold, but there’s no steady maintenance work being done on them. At best, a product is returned to when its lack of maintenance becomes a problem, but at worst the product simply rots. 

Software is sold as if it were wine, but in practice it ages like fish. Without attention, it starts producing problems. A company may choose to say that nothing is wrong with this. Aside from one’s ability to sleep at night, this may not work out so well. If the product was sold to customers, there’s likely to be a contract requiring maintenance. One can argue this is less of an issue with products that are offered as free supporting material to a commercial product or service, but practically speaking there’s not a lot of difference. 

The nasty failure modes

All of that is just a model allowing morality and economics to play out with Parkinson’s Law, though, and there’s nothing specific to the squad model in it. Squad model is simply a mechanism, potentially allowing pernicious behavior but not forcing it. Here are the ways that I think this model can actively fail the software development organization.

  • Product managers and executives are shielded from their responsibility to kill product that isn’t working. A poorly performing product isn’t EOLed, it’s just deprived of any development time. “We aren’t putting Old Yeller down, we’re just not feeding him and waiting for Nature to take its course.” Killing a product that isn’t selling is one of the harder tasks in product management, and a team that doesn’t really have to is going to find a way to avoid it. Squad model keeps false hope alive for bad products. Surely it would succeed if it just got some resources? And surely those resources are just around the corner, at the next planning cycle. And so the zombie product shuffles along.
  • Engineers can’t focus on long term improvements or tech debt reduction. Of course everyone complains about this when they don’t do squad model, but the squad model actively makes this situation worse by adding churn costs. At best, developers are coming and going in squad sized chunks but a continual skeleton crew is always on deck. At worst, the product lays fallow between development cycles. For each introduction of people, the cycle of course looks like this: 
    • Spend a sprint or two spinning up to understand the subject matter domain, product design, existing codebase, and plan of attack
    • Bandaid the immediate problem the squad was brought in for, ore or less well
    • Spend a sprint or two patching the worst bugs and documenting your work before you move on to something else. 
  • This isn’t enterprise software any more, it’s professional services. Why’s that bad? Because enterprise software businesses are exponential money makers, but professional services businesses are linear money makers. It’s an oversimplification of course, but based on the observation that services are inherently customized to the client while products are generalized. In the squad model, the projects that the customers buy are now the clients, but the developers are still moving to where the dollars are today instead of skating to the future puck.
  • It doesn’t take long for leadership to spot these failure modes, so it also doesn’t take long for correctives to be applied in order to smooth out churn and allow for maintenance. The result is that engineering is split into haves and have-nots. Some squads will be put onto those long-term work items that suffer from shifting resources. Maybe it’s called a Sustaining team (probably lower status), or maybe it’s a Platform team (probably high status), but the effect is the same: parts of the world have to keep working as they did before the re-organization and those engineers are now on an island. Is this expressed as a pendulum swing back towards the prior organization, or as a bold stride towards a new future that simply looks a little familiar? Regardless, the development organization now has another source of cognitive dissonance to discuss.

At best, it’s not worse

As we often say in the business, “it’s software, you can do anything with sufficient time and money.” None of what I’ve described is necessarily fatal to a development organization, and indeed some might welcome a splash of internal cognitive dissonance to distract from their external issues. But in my opinion the model isn’t great at meeting its stated goal, which means it’s not a useful way to allocate resources in my opinion.  Ostrom’s Law states that “A resource arrangement that works in practice can work in theory”, but I strongly suspect that’s exactly what we’re seeing here. The massive productivity made possible by enterprise software development allows for a wide variety of otherwise non-productive resource arrangements to maintain effectiveness, regardless of their actual merits or efficiency at producing more quality software.

Other

Monday, March 1, 2021

Purge Outlook Emails

Ever have to convert from an email system that encourages keeping everything to one with limitations? Well, here's a way to encourage Inbox Zero. I looked at a few different scripts to start from, but this one was the most helpful. Note that this only works with “old” Outlook, new Outlook has no AppleScript support at this time.

Sunday, January 17, 2021

Penny Wise Hardware



Thesis: Organizations will continue to squeeze their highly paid people into the worst possible computing environments in order to block any accidental efficiency that might evolve in their organizations.

Evidence to support that thesis:

  • Five year desktop hardware refresh cycles for workstations (that’s on service plans of a year or two and warranties of three max)
  • Four to six years for servers
  • Single CPU virtual desktop instances: you haven’t been able to buy single core hardware since early 2012, but you can still try to run Windows and productivity apps together on one core.  Plus, an endpoint agent from every team for for every purpose, mostly blasting raw data into central lakes because there’s insufficient local resources to accomplish their mission. 

Of course the thesis is silly, no one really means to starve their organization. It just happens by accident, through priorities shifting and a blind eye on poor metrics. Performance monitoring for endpoints is a worthy investment.

Easygoing, Right, Wrong, and Difficult


This post is an expansion of the concept in Valuable Jerks.

Say your team has a project that needs execution. Launching a new product? Trying to land a customer? Trying a new process improvement? If it’s at all interesting, then it’s not obvious what to do and that means leadership is trying to form and communicate plans of attack.

Let’s use a quadrant to look at how that might go. 

  • Vertical axis: easy to work with versus hard to work with. 
    • Easy-going has lots of friends and is always busy because they’re invited to everything. They don’t rock the boat. Stable.
    • Difficult can’t compromise, causes friction, makes waves. They’re disruptive. Volatile.
  • Horizontal axis: wrong versus right. Everyone in the team is asking themselves, “Is the plan going to work?” This one can be tougher because in some problem solving situations no one really knows the right or wrong answer until a thing is tried. So let’s disregard how the plan will actually float in reality later, what matters in preparing and building a solution is the team’s opinion of the plan. If they don’t believe, they’re not going to swing for the fences.
    • Wrong is unable to produce agreement that their plan could work. Perhaps this is a failure of vision, a failure of communication, a failure of knowledge or experience. For whatever reason, the team has Capital C Concerns.
    • Right is able to produce that agreement, and the team more or less agrees with the approach that they suggest.

Now for the magic of social interaction... Easy-going trumps Right or Wrong.

  • Wrong and Difficult? Seems obvious that this leader is not going to have an easy time. Their idea is unpopular and so are they. If they don’t have the skills or temperament to change one of those things, a performance improvement plan can be expected. And since they’re not easy to get along with, they will need to do something drastic to impress everyone that they’re actually right.
  • Not like Right and Difficult has it much easier. Sure, the team agrees that the leader is heading the right direction, but every day is a struggle. Since it’s already a struggle to do things that are worth doing, struggling over mundane tasks like shared situational awareness is kind of a waste. The Right and Difficult leader may have the charisma to inspire followers to put up with their difficult behaviors (insert your favorite exemplar here), but it’s still an unnecessary self-own. Unless an unhealthy team dynamic is the goal of course.
  • But Wrong and Easy-Going? This leader’s team may well give them a pass. Even if they don’t think the plan is right, daily activities can proceed just fine and the boat is not rocked. Delay is a natural outcome, because there’s rarely pressure or challenge. This leader might be rotten, but it’s going to take an outside force (such as a leader from above or a customer complaint) to drive change.
  • Finally, the golden quadrant: Right and Easy-Going. Everyone’s happy and the project swims along until real life provides some objective feedback.

Relevant: Rands In Repose 


Saturday, January 16, 2021

Communication in Teams


Question: how should your team ensure that other teams know everything you’re doing so the organization is more efficient?

Answer: Use all of these tools.

  1. Push regular broadcasts of information (note that everyone will complain that the format sucks, the medium sucks, and the information that you provide is both too general and too specific)
  2. Provide a pull resource, such as the broadcast material in a shared location, and post links to it everywhere you can think of. (note that everyone will complain it’s badly organized and hard to use)
  3. Accept that some teams will continue to ignore and misinterpret (willfully or otherwise) all of this and do what they were going to do anyway.