Companies Lie To Themselves

Posted by | Uncategorized | No Comments

I have a bone to pick. Having worked for a decent amount of enterprise focused software companies now, I’ve determined something that truly bothers me. I think this may be very specific to software (perhaps not though!).

Companies are constantly lying to themselves – and it’s making them worse.

I mean this in particular towards the sales and product teams. I understand why they do it but I disagree with the entire premise. Here’s how it goes.

We’re in a competitive deal. There’s multiple other potential vendor plays. It’s the final stages of the deal and BAM! The champion delivers the email no sales person wants to hear: “We went with another solution”. The org starts freaking out, tries to save it, but ultimately can’t. We send in competitive research to do a post-mortem and figure out what happened. Then, we send out an email to the broader organization, generally saying something like the following:

  • “They weren’t the right market fit size for us”
  • “They didn’t have enough budget and we were too expensive for them”
  • “They aren’t mature enough yet for our solution”

Here’s what I don’t like about the above: none of it comes back on the company. It often times feels like we pass the buck on why things didn’t go well. While statements may be true, there is significant product development feedback in each of those quotes.

In a little bit of a rant, what I hate about it is it creates a culture of “us vs. the customer”. Teams read through the emails and don’t view it from the lens of how we, as a company, can do better. Where we can improve on in the product, whether our pricing structure makes sense, whether our product messaging is hitting the right audience, whether it’s easy enough for users to use our product, and so on. We say things like “well, guess that customer is going to miss out on how awesome we are”.

It’s that bravado that drives me nuts. Part of building software is the relentless effort to improve the offering and capture the largest market share possible. Now, I get that we don’t always want to do that. Sometimes we really don’t want to sell to SMBs because they have budget constraints and really aren’t mature enough. But what I’m trying to hammer home is that the culture of what we do with that information is what drives me nuts.

Extremely high performing organizations look at every loss as a stab wound. They triage it and figure out what moves they made that exposed them. They believe they are at war and feel that making a mistake jeopardizes their god-given mission. They weaponize the loss and turn it into energy to improve.

Bad performing organizations love the smell of their own shit and believe they’re building something akin to a cult where the customers are “lucky to have us”.

Don’t be like the bad performing organizations. Don’t be scared of worrying your employees by sharing what we need to change or improve on. Create best next action items from the loss on how to improve. Instead of building a culture of shelter from that loss, build a culture of weaponizing losses in to gains.

My Job is Me

Posted by | Uncategorized | No Comments

I had yet anther interesting and fun conversation with my colleague who sparked a fun question: why don’t people hire me because I’m Matt?

Here’s the back story. My colleagues and I interview a lot of different candidate each week. I think our average right now is probably 3-5 candidates a week ranging from entry level positions to director level. We’re hiring them for a specific job, such as Director of Engineering or Product Manager over a certain domain.

It’s always interesting being on the interviewer side because we get to briefly review a resume that has a list of accolades related to their history that maps to the job they are applying for. We often come in with strong assumptions around whether we are going to like the candidate or not. It’s hard not to be biased in these situations because we often know what we’re looking for and the words on their resume either map or don’t to the job description.

What we often find is that we’re wrong on our assumptions (rocket science level statement right there!). The problem is that we often really like the people we interview but they just aren’t a good fit for the existing role. Otherwise, we’d hire them in a heartbeat!

Part of what is tricky is that everyone has what they’ve done on their resume but there’s no context on how they got it done. That’s the art form that is missing. It’s not on there because it would look super weird and potentially off putting if someone said “Drove $5M in revenue through strategic political bachkchanneling” or “Rapidly pushed product through to the market by obfuscating a department through automation”.

Here’s the real ugly truth that’s a bitch to explain in reality: those traits are implied both in what an interviewee has delivered and how they explain that in the interview process. No one will every outright say that they had to make a massive political campaign to get the ball over the line, but rather explain it as “I influence the right people to move it forward”.

What we see is the job description and the resume. What we don’t see, and often don’t hear, is the art form in which they accomplished that.

For example, within product management, there are a ton of different ways to get the job done. There are general qualities that you want to look for but it really is an art form much like any other role. Product managers can be really strong on the quantitative analysis. They can be heavy on the business model side. They can also be a pure play product manager where they heavily focus simply on delivery to the market. They can be technically focused. The point is that they come in all different shapes, sizes, and expertise.

Now, I’m sure folks will argue that a product manager should have qualities that cover a wide range of the above skills sets. I don’t disagree but the reality is that individuals will skew in certain directions based on their education and experience. Finding someone who is well rounded in all of them is finding a unicorn and, I’d argue, someone that you actually don’t want because they are likely too shallow in each domain.

This goes back to the beginning of this post which is this: why can’t people hire me for me? It’s true that companies need specific skill sets at different stages of their life. But it would be interest to see a different type of hiring model where instead of hiring specific skills, we instead hire for art form styles of a domain. Meaning, we qualitatively look at an individual who has applied for a job in a certain domain (eg. UX, product, etc.) and identify how that individuals unique art form maps to areas of where the business needs.

There are some companies that do this by saying “we’re hiring product managers” and then map an individual to a product line of interest or art form need. Those are the minority, however, and it would be really interesting to see if both the employee and company are more happy than the traditional route of hiring.

At the end of the day, I want people to hire me – Ryan – because I have certain valuable skills but have an invaluable art form of applying those skills. I think that’s where the intersection of happiness between employees and companies may stem from.

Visualizing High Performing Enterprises

Posted by | Uncategorized | No Comments

In my previous posts, I talked through some of the interesting findings from our research at Workfront around analyzing 600M hours work getting performed across tons of different verticals. We found some interesting stats like the avg. number of people on a project is 5.4 or that 76% of work created and completed comes from a process.

We took it another step further to better understand what it looks like to be a high performing enterprise. Our mission at Workfront is to help companies operate better and to make it so that people know their work matters. To do this, we need to see what it looks like to be a high performer. We know what the numbers look like but that only took into account a couple of variables.

Our work primarily focused on how we can accurately predict whether a project would complete on time. We extracted a handful of features that we had high confidence on, created a training data set, then ran the numbers through an exploratory machine learning pipeline. This included models such as neural nets and SVMs which helped us figure out which model could consistently deliver us predictable completion dates. It’s worth noting that we had to do a lot of data normalization and transformations in order to make the numbers work out. For example, it’s hard to visualize a process that takes only 5 days to complete versus a process that takes 500 days.

What we found was like any data exploration effort: the data tells a compelling and actionable story. We found that a best-fit line that was equal and the “x” and “y” axis through our visualization represents a fairly optimal work process. When the line skewed higher on the y-axis and less on the x-axis, companies we’re dramatically underestimating the effort required to get work done in their processes. Conversely, if the line skewed lower on the “y” and higher on the “x”, it means that the organization was dramatically overestimating the complexity of their work and that they could take on more work should the learn to optimize their process.

1 – This means that users had high accuracy of their plan vs. actual minutes and our model was able to accurately predict project duration. This is the ideal state.

2 – This means that users underestimate how long projects will take. They take on too much work, rebase their delivery dates, or have poor scoping practices. This is a non-optimization process.

3 – This means that users over estimate work efforts and have not gone back to optimize their processes. The org “looks” busy but can actually take on a lot more work. This is a non-optimizated process.

Below are a couple of high performing and predictable organizations.

When we visualize organization that we can readily predict their delivery dates, we get an interesting pattern. The tighter the scatter plot, the more consistent and predictable the organization. Curiously but not necessarily surprising, we also found that these organizations completed an order of magnitude more work than organizations with a wider scatter plot.

Don’t you love it when you find little gems like that in your data? 😉

Below are a couple of low performing and unpredictable organizations.

You can easily see that the data points have a much wider distribution which means that we weren’t able to get accurate project completion date predictions. It’s also easy to see that there is a significant less amount of work items being completed.

Now, one flaw with saying that the amount of work an organization can complete due to a process is that not all work is equal in complexity and size. That said, I would still say that this is a good leading indicator that there is a decent amount of truth that shows these work items are close in size. We found that the top 10% of processes that generated 80% of the work had an average of 12 tasks per process. Qualitatively, we also know that many organizations use their processes for fairly similar use cases (Eg. marketing campaign, product prototype, etc.).

We’re doing a lot of fun data explorations such as this in order to better understand user behavior and how to contour our software to augment users to be more efficient. It’s a journey through the data that requires a lot of time and a love of the labor, but we continue to find fascinating aspects that drive our product roadmap into new areas.