Category Archives: Software Business

PM-led vs. Engineering-led Time

At Trello, on the mobile team, we had a formal way of allocating engineering time to either working on PM-led or Engineering-led initiatives.

A PM-led initiative was something that ultimately rolled up to a OKR that was well-understood by the business. The requirements came from the PM and the PM could assess acceptability. An Engineering-led initiative was something like tech debt, changing our dependency package manager, improving CI build times or anything where the requirements came from the team itself and the PM didn’t know or care about it (and neither did anyone outside the team).

So, let’s say we decided the split was 60% on product manager led initiatives and 40% on what we called engineering-led. The split is arbitrary—the EM and PM agreed on what was appropriate for their team and set it for the year.

Then, any individual engineer at any one time (for a couple of sprints) was on either a PM-led project or an Engineering-led project. We did not want a single engineer to be split across PM/Eng-led work. This made it easy to know we were allocating correctly (without having to track time on individual stories or cases).

So, if it was 60/40 and we had 10 engineers, 6 would be on PM-led, and 4 would be on engineering-led at any one time, but it rotated.

This just needed to be mostly right over the course of a year—on any specific month it could be a little off if over the long-term, it matched.  For example, If the PM didn’t have work ready, we could do more engineering-led work temporarily.

Monetizing Waste

I did some consulting for a major industrial chemical company 20 years ago and one of the interesting lessons I learned was to use my waste.

Each chemical process they ran generated the desired output and some waste products. But, they thought of that waste as just another chemical compound that could be the input to another process. A big part of the business was designing and selling products that made use of waste that was being produced. For that new product, the waste had negative cost because they would have had to pay money to dispose of it.

Using waste helped me start App-o-Mat. I bought the domain as soon as the AppStore opened in 2008 because I thought it was a cool name. I didn’t do anything with it, but kept paying for it every year.

In 2013, I decided to leave my job and do consulting full-time, and I was hired to write an app using Cordova (PhoneGap). At the time, the online documentation for it was pretty bad, but I had figured it out and made my own template for projects that brought together and configured the most useful plugins I found to make Cordova apps look and act more like native ones.

But, I still thought that Cordova too hard to learn, so I made a YouTube tutorial series showing how to use my template and build a minimal blog reader app. I put it all up on App-o-Mat.

App-o-Mat has been valuable to me in two ways:

  1. It has generated leads for my consulting business
  2. The site itself is written in Django, which kept me sharp in Python and web development during the time I was doing iOS full-time.

But I might not have done it if I didn’t have some waste product I could use to get it started.

Money Dials in Software Design

When I read I Will Teach You to Be Rich, I learned to concentrate on increasing income, not reducing costs. In that same book, Ramit Sethi also talks about the concept of money dials.

There are some things that you love so much that you would be willing to pay more to get a better version. You turn those dials up, and then you ruthlessly cut everywhere else.

The concept of money dials also applies to software product design. There are some things in your software which make it unique and valuable—is there a way to turn that up? Can you invest so much along those lines that it would be impossible for competitors to copy?

To afford that investment, what do you not need at all? What can you reduce to the minimum? It’s not just that it would cost less, it’s also less code and possible legacy thinking that stops you from making progress on areas where you have turned the dials up.

4DX: Applying the Second Discipline

The second discipline of The Four Disciplines of Execution is to act on lead measures to accomplish the Wildly Important Goal (WIG). I defined my three WIGs yesterday

  1. Work: no launch blockers in the product by March 31, 2024
  2. Fitness: Go from 23% body fat to under 20% body fat by December 31, 2024.
  3. Personal Growth: Write two 50-page books and put them up for sale by the end of 2024.

For each of those, I have inherently expressed them in a way that defines a “lag” measure. On March 31, I will have launch blockers or not, but there will be nothing I can do on that day to change it. Each day, I will go on my scale and see my body fat %, but I will not really be able to do something that directly affects that in the short term.

4DX asks us to define lead measures that are things we can do right now that will lead to us accomplishing our lag measures. It measures our real-time activity, not the end result of the activity.

For work, it’s going to be time spent coding on launch blockers. I think I can get through the list if I spend 4+ coding hours on launch blockers per week. That might seem like too little—which is common in 4DX goals. You must accept that you still have all of the operational things you have to do. My partner and I are still experimenting, supporting early users, and possibly pivoting. I obviously need to work more than 4 hours per week on the project, but the majority of them are spent dealing with what the business needs today. My WIG is about how we get to the next level.

For fitness, I am accepting that my amount of body fat is very hard to lower (I have lowered it a lot, but have been stuck for a year), and so I am going to work on my amount of muscle mass, which means that I will do more strength training. My lead measure is to do 4 sessions of 10+ minute weight training workouts per week. It’s not 4+, because rest is important. It’s only 10 minutes, because I am working one body part fairly heavy and to failure. I am doing other workouts—these are in addition to what I am already doing, usually on the same day.

To support this, I am adding a secondary leading measure of eating a high-protein, lower carb breakfast 5 days per week. I usually eat oatmeal and fruit, which is perfectly sensible, but perhaps not supporting my WIG as well. I am not a low-carb person (quite the opposite), but I want to reduce this kind of carb. My new staple breakfast will be an egg substitute I make from soaked mung beans (similar to Just Egg) and tofu or tempeh. There is also a cafe near me that makes Just Egg omelets that I will have when I’m lazy. I might also use protein shakes, but rarely.

For my personal goal, since I am aiming for 50 page books, it might be tempting to have a weekly page count goal, but that won’t work for me because I write in drafts. Like my work goal, I think the easiest lead measure will be hours per week, so I will work on the book for at least one hour on five days per week. This will result in 5+ hours per week, but I think it’s important to have a daily practice of writing and not just do 5 hours in one day per week. It seems low, but I have other things I am doing besides this to maintain my level of output. I still want my blog and podcast to be going at the same time. The WIG is about what I can do to get to another level, not something I do instead of what I am doing now. In 6 months, that’s about 130 hours, which should be enough time to write and edit 50 pages.

You might disagree with my goals, and how I am trying to accomplish them. That’s ok, but that’s not the point. The point is that I am trying to accomplish big goals by concentrating on a process that is much more short-term and something I can definitely do (4DX calls this playing a winnable game). I will be checking in every 13 weeks to see if I am moving the lag measure, and adjust if not.

How I am applying The Four Disciplines of Execution

I read The Four Disciplines of Execution (4DX) a few months ago. It was recommended to me several times—I wish I had read it sooner. It’s in the genre of business productivity systems, which is not surprising since one of the authors, Sean Covey, is the son of Stephen Covey (author of The 7 Habits of Highly Effective People).

Like many books in this genre, the book is part of an entire ecosystem, with courses, videos, etc. You can get a good overview there.

Here is a quick summary of the 4 disciplines (it’s more complex than this—the book is worth reading for details)

  1. Have a single important goal that would make a meaningful difference (in your business, life, etc). This will have some lagging indicator.
  2. Figure out a leading indicator that you can act on and track. This is something you can do every day that will build up to the important goal.
  3. Build a compelling scoreboard that tells you if you are winning (achieving the leading indicator).
  4. Have regular (weekly) accountability meetings where you only discuss the goal, leading indicators, and how to put points on the board

To give an example, here’s how I am applying it to my fitness:

  1. Important goal: Reduce Body Fat %. I am doing this primarily by increasing muscle mass. My lagging indicators are goals in bench press and strict pull-ups.
  2. Leading indicator: Days per week doing resistance training.
  3. Scoreboard: I track the workouts on my Apple Watch. I can see the count in the fitness apps I use. My scale tells me Body Fat % to make sure I’m on track. I am also tracking hours in Zone 2 and higher as a secondary indicator.
  4. Accountability: I review it weekly and schedule the next week’s workouts. I also go to Crossfit, which gives me access to coaches that can help.

My personal growth goal is to publish some pamphlets (short books) this year. Here’s my 4DX

  1. Important goal: publish pamphlets. Lagging indicator is 2 books.
  2. Leading indicator: Hours writing per week.
  3. Scoreboard: I’m using personal productivity software that I am working on.
  4. Accountability: I am making season four of my podcast about this where I will discuss my process and progress.

My work goal is to launch the productivity tool I am working on

  1. Important goal: Launch
  2. Leading indicator: Hours coding
  3. Scoreboard: Also tracking in this tool
  4. Accountability: I have weekly meeting with my partner where we discuss progress.

All of my leading indicators are in SMART goal format: Specific, Measurable, Achievable, Relevant, and Time-bound. The main difference is that they are very short-term and more about process.

Obviously, it doesn’t matter if I achieve the leading indicators, but not the lagging ones—the lagging ones are the real goal. The idea (from 4DX) is that leading indicators are something you can act on and track each day. You trust yourself to pick things that are likely to result in the bigger goal. You adjust if they aren’t.

Comparing People is Not Transitive (Another Reason Why Stack Ranking Doesn’t Work)

Layoffs are hard, but we shouldn’t try to make it easier with stack ranking because ranking is inherently one-dimensional and forces you to compare pairs of people. For layoffs, you should want to compare different multi-dimensional teams.

In programming, we know that whatever algorithm you use to sort a list, you need a function to compare two items. But sorting this way only works if comparing is transitive. This means that if a<b AND b<c then a<c. This works for numbers, but you need to be careful when you make your own comparators.

There’s no natural way to order people, so when you make one up, it’s often not transitive. The second problem is that the comparator only has the two people to compare, not any other context. That means that when you are considering the “value” difference in a pair of people you are not using the context of the team that they will be on.

Instead of sorting, consider this visual aid:

A spike graph that shows multiple dimensions

I explained this graph in Raising The Bar is a One Dimensional Concept. Each spike represents an attribute of a team member that you value. For example: coding skill, team gelling skill, writing ability, domain knowledge, code-base knowledge, mentoring—you can have as many as you want. Your team members may each excel in some, but lack skill in others. For each member, put a dot somewhere on each spike of the graph and connect it to make a polygon. By overlaying the individual graphs, you can see if you have a balanced team with diverse abilities and interests.

Here’s how I suggest you use this. Let’s say you have 10 developers and you need to lay off 20% of total salary. To decide, try evaluating each member on all the dimensions you value and create a team using your budget to pick the ones that result in the team you want.

Let’s say you start with some obvious top-performer. They have the most seniority, have mentored well, write great documentation. They are all-around a person that you want to keep. The next person to add is probably not someone similar to that. You want to end up with a good mix of junior and senior people, so the next person might be someone relatively unskilled, but perhaps with other desirable attributes.

The key is that you are thinking of that junior person in combination with the senior one, not comparing them against each other. To the extent you are comparing team members to add, you are considering which one is a better multi-dimensional addition to a multi-dimensional team, not looking at them in isolation. As you build up the team, you may notice things the team needs, and pick the next person based on that. You should try this a few different ways, with different starting points, and see if they converge.

Instead of thinking of people that you need to cut, you focus on building the best team you can afford. You should already know how to do this because this is a good way to recruit as well.

You Can’t Rank Order Multi-Dimensional Things

One of the most surprising things I learned in math was that complex numbers had no natural ordering. Meaning, less-than and greater-than are not defined for complex numbers. It makes sense when you think of it for a minute. The same applies to other multi-dimensional things like matrices and vectors.

So, why do we think we can rank order people? I’m specifically talking about companies that do this for their employees, but it comes up in other contexts (e.g. class rank).

Even if you were to think of people as a number, it wouldn’t be expressed as a 1-dimensional one. When I wrote about the concept of lowering/raising the bar, I said that that a bar is a 1-dimensional concept. So is rank ordering.

Just like with complex numbers, you can make up an order if you want. But then you lose information. For example, if you choose to order based on magnitude, then direction would no longer matter. Similarly, when you rank team members by, say, seniority, you lose orthogonal characteristics, like the ability to catalyze others.

The reason companies do this anyway is when they are looking to downsize. If they do need to lay someone off, it might well be the lowest ranked person, but it’s a terrible way to do this. I do have a suggestion, but I’ll get to that Monday. [EDIT: Here it is – Comparing People is Not Transitive]

Your First LinkedIn Message Should Not Be a Lie

Every week I get a few messages that start “I was looking at your profile and I noticed …” or something to that extent, and then they just have some generic, irrelevant pitch. They absolutely did not look at my profile. If they had, they would not have bothered contacting me. So, their very first words were a lie.

I’m open to being contacted by strangers on LinkedIn. To some extent, I am interested in how people contact others to see if I can learn. So, I should be thankful that I learned how much I hate this kind of opening, so I will never use it.

Triangle Estimates

I estimate using time, not points. I do this even though I have mostly worked on product development teams inside of companies and not as a contractor for clients.

But, estimation on product development is not as high-stakes an activity as it is if you are billing based on it. The judgement of a successful product development project is based on whether it moves some business needle, not whether it was under budget. The margin on successful product development dwarfs reasonable overruns. There is also a lot of appetite for risk, where we know that we’ll win some and lose some.

That’s not true if the work is for clients. If they pay by the hour, they expect the estimate to be accurate. But there are very few (if any) big software projects that can be accurately estimated. When you’re wrong, you either have to eat it or have a very difficult conversation.

I don’t have a good answer, but I would start with triangle (or three-point) estimates. To use them, you estimate a most-likely estimate and then a best and worst case on either side. The three numbers describe a distribution (see the wikipedia page for how to combine them). The result is an estimate with a error range and a confidence interval. I would recommend sharing that instead of a single number.

The only task management system that I have seen that offers this option is DevStride, which carries three-point estimates throughout its system.

The Ending Should Oppose the Beginning

In episode 44 of Scriptnotes (transcript), John August and Craig Mazin talked about how the ending of a movie should relate to the beginning. One thing Mazin said made this clear:

… if you’re writing and you don’t know how the movie ends, you’re writing the wrong beginning. Because to me, the whole point of the beginning is to be somehow poetically opposite the end. That’s the point. If you don’t know what you’re opposing here, I’m not really sure how you know what you’re supposed to be writing at all.

In my post about The James Bond Opening to a software demo, I recommended starting with something exciting about how another customer is getting value. This should be short and sweet and gets the prospect to lean forward.

But next, talk about the problems the prospect is having right now, which you learned about in discovery. Remind them of this as you start their story—the one you are about to tell, which will take them from their life now to a new life after they buy your software. By the end of the demo they should be convinced to take the next step.

If you want to learn how to tell stories like this, I recommend learning how screenwriters do it. Scriptnotes is a great place to do that. They know how to tell a story where a protagonist makes a decision that inevitably leads them to a changed life. This is like the story you want your prospect to feel they are in.