Last night, I went to a local meetup where we played Legos. It was an event organised by Krzysztof Niewinski. In particular, it was a simulation workshop of large scale product development using alternative organizational structures. But there were lots of colored bricks involved. And the specs were pictures of the end products that needed to be built.
Without getting into too much detail, we covered 3 alternatives with the same group of 20 something people: component teams, cross functional teams of specialists, and finally "T-shaped" interdisciplinary teams where everyone could do everything. In short, we were experimenting with output using alternative ways of working. Each round took roughly 10 minutes.
Here's what happened
In the first round, we had specialized component teams each dedicated to working with only two different lego colors, a supply team, an integration team, a quality team, and 8 different product managers who wandered from table to table. Sound familiar? Kind of like a massive construction site with lots of project managers. Or in a large company developing and installing software. Most of the building teams sat around doing very little in practice. There were lots of bottlenecks and confusion around getting supplies and exact requirements. I had a chance to engage in chitchat with my table mates. And a stressed out senior executive that walked around and yelled at anyone for not doing anything.
The second round, we continued to have individual performers who were specialists, but they worked together, which resulted in a lean assembly line. The time required to first output went down almost 50%. But there was less top down control. And more legos on the table, relative to the previous round.
And finally--the last round--everyone pitched in and contributed how they could. There were still some constraints, in that people working outside of their expertise could only use their left hand. Despite that, it only took a minute to get the first outcome, so almost 9 times faster. But there were lots of extraneous legos on the table. It was lots of fun, and it was a very tactile learning experience for everyone who pitched in. Just like kindergarten.
What does this mean
This boils down to control, profitability, and speed. This is just as true for startups as it is for large companies. Most of the conflicts among co-founding teams boil down to differences how founders value control and money, according to Harvard professor and researcher Noam Wasserman in Founders' Dilemmas. In big companies, any larger product development program will implictly or explicitly make a call on these three, based on how the work is organized. It depends on what you optimize for, as Krzysztof the facilitator pointed out.
The construction site was optimized for control, especially of costs. There were enough people to do the work, and enough legos could be procured if you were willing to wait. But the level of resource scarcity locked up the system, relatively speaking. And it took a long time to finish anything.
The assembly line required a slightly larger up front investment but the speed at which things happened increased dramatically. Even though the constraints on each individual were exactly the same. As an expert in yellow and green bricks, I was still only allowed to touch these, even though the configuration was completely different.
The kindergarten required even less top down control and more resources, as well as trust that the teams will get on with it. There was be a higher use of resources (lego blocks laying on the table). At any given moment, you won't know exactly what is going on, because everyone is contributing and collaborating. The teams were releasing stuff like crazy. So at that point, does it really matter that you need a bit more money up front? If they are releasing stuff so quickly, presumably this translates into revenue, which keeps the kindergarten afloat and then some.
Choosing the metaphor works that best for your company
The way you organize the work matters. And it feeds into culture. Larman said "Culture follows structure". In a software context, it means you want to allow for chaos and experimentation. And not really just squeezing features out of development teams.
As a company scales from a successful startup to a larger company, the trick is to keep enough of that "kindergarten juice" in the culture and in how the work is organized, in order to allow your company to continue innovating. If the emphasis on control changes as a product matures, you can introduce more of that as needed. But do so consciously, and watch your output and outcomes like a hawk.
By micromanaging the process, even as an assembly line in a feature factory, you're still missing out on pretty big upside (assuming you care about having lots of new products released).
That said, even a kindergarten needs boundaries. So that the teams don't cut corners in quality for example. That's kind of the point. There are a handful of non-negotiables around safety, health, and security in a kindergarten, and everything else is optimized for discovery.
So for a bunch of interested strangers on a random school night, who dug into a few alternative structures and held everything else constant, it was clear that there could be very large differences at play. 14x faster, not 14% faster. These would be results any agile or digital transformation program would love to achieve. That said, it wasn't clear if these differences came from structure only, or the culture around it. And if culture is involved, that could be what's preventing the massive change in the first place.
Key Takeaways
The way you organize work matters, and it feeds into the culture, particularly in a larger company.
By organizing work, you will be making choices about tradeoffs among variables that matter.
Control, in particular, seems to be inversely related with learning and speed.
Due to his glasses, Michael's estimate of Jane's distance from him is 14.3% further away than she actually is--at any given moment. How would you describe his estimate?
Precise, but not accurate.
Wait, what's the difference between the two again?
Precise means the numbers you are seeing are repeatable. Often down to multiple digits after the decimal point. You can be pretty confident that when you do the experiment again, you'll get the same result.
But that's not necessarily true with an accurate result. An accurate result is one that is close to the actual value. For Michael's scale to be accurate but not precise, it would be producing numbers close to the actual value, but not the same number each time. In estimating knowledge work, accuracy bests precision.
accuracy and precision 2x2
This above 2x2 applies to estimation of work in a knowledge work context. Ideally, everyone involved wants estimates to have both high accuracy and high precision. But at the beginning of a new initiative, it will most likely be low accuracy and low precision. Because at that point you know the least you possibly can. From the example aboce, Michael's estimate lies in the top left box. However, what we actually prefer to that is the bottom right one...if we can't have the top right. High accuracy makes it much easier to plan out the upcoming work.
One way of skewing towards accuracy and away from precision is by making it difficult to be precise. Instead of trying to estimate absolute sizes of stories, i.e. 3 days, we can estimate only relative size, i.e. 2 story points.
Relative sizing gives us enough to negotiate business priorities given the size of each story, without tempting fate in terms of blaming: "You said it would only take 3 days, and blah blah blah". This isn't healthy, productive, or fun. So why even go there?
These relative sizes still allow for some reasoning; however, direct numerical inferences are deliberately imprecise. For example, you can add up how many story points there will be for a larger epic. You will need to allow for a lot of variance on the individual stories. But on the basis of the "law of large numbers" from statistics, this variance will tend to average itself out. Based on this you can get a feel for how one epic compares to another for example.
1. Estimate story points directly
For this, the first place to start is the Fibonacci sequence, as a way to express relative size. They're numbers. The sequence itself is very simple. Each number in the sequence is the sum of the preceding two values. This ensures that it roughly doubles each time a new number is generated, but not precisely (Hah! low precision!).
The Fibonnaci spiral formed by drawing a curved line from opposite corners of squares
There are visualizations of the Fibonacci sequences like the one above, where you can see that there is a clear difference between each step. In practice, this type of sizing will help you get beyond a "to do list", where everything seems to be the same level of effort. It's not. And that's the point.
Here is a recommended breakdown in my favorite free tool for estimation: planitpoker.com:
Above 20 story points, you probably need to break it down into smaller stories...
It's typically good to top out at a maximum size to make sure that stories stay small. Over a certain size it just feels too big, and the estimation discussion stops being useful. At that point, a big story should probably be broken into smaller subtasks, each of which should be estimated using the above sizing numbers.
2. Translate T-shirt sizes into story points
For teams struggling with letting go of absolute estimates, the T-Shirt approach gives you the best of both worlds. Essentially you have the team estimate using relative T-Shirt sizes. Then you translate the team's input into story points. This reinforces the relative nature of story points, while still giving you something more concrete to work with for velocity purposes.
Use TShirt sizes and translate them to story points later
Using the planitpoker.com interface, you can set it here:
Flip to the TSHirt sizing option to go ahead with this approach
3. Ron Jeffries' option of 2 days max/task
This option came out of a big debate years ago on the scrumdevelopment yahoo groups mailing list. I admittedly have never tried this myself, but it's worth considering as an alternative approach to estimation. Or a thought experiment at minimum. Basically, at the time Ron Jeffries (@RonJeffries) was arguing against estimation in general. He posited that:
we should stop estimating
limit stories to 2 days of work
if you expect a story to take longer than 2 days, then break it down into multiple sub-stories
This way, you significantly reduce the need for an explicit estimation discussion. And you can manage workload and scope based on the number of issues you want to complete. If stories are assumed to be of equivalent size at a worst case scenario, i.e. 2 days/story, then you can derive your delivery date from the number of stories you have. Assume all remaining stories take 2 days, i.e. the worst case scenario, and add the number of work days to today's date.
In practice, stories are often larger if they have "business value" and therefore can't be easily broken down. Thus it's hard to pigeonhole them into such a framework. By business value, I mean anything that would be of value to a customer for non-technical reasons. But you can put such a limit on sub-tasks of stories. And therefore just count the number of sub-tasks.
This approach kind of turns software development into a release checklist of stuff that must be finished. All of the tasks are small. It also means that there are a lot of stories and tasks flying around. This require extra management & coordination work to maintain it. Either by the team or a delivery manager.
And also I suspect it's hard for senior stakeholders to see the forest for the trees, if you just have a long list of tasks. What will be done by when? Even though you can change the order of what's done, it's hard for anyone who isn't intimately involved with the details to understand what's happening at a glance.
Finally, I do think in this case you lose out on the design discussions which happen during estimation. You only break down stories or tasks if they are "too big". Therefore, you won't ask questions like "what is the best way to approach this?" before starting the work. It could impact the quality of what's delivered. And also get team members to spend time on work that is thrown away or low priority. In my opinion, this is human nature. We need to be deliberate about priorities; if we're not, they won't happen.
So here are a couple of aspects of this approach this Ron himself points out when using this approach to figure out when we'll be done:
What if all stories were approximately the same size. Then what could we do with story estimates that we couldn’t do with story counts?
What if all stories were one acceptance test? What could we do with story estimates that we couldn’t do with story counts (or, now, acceptance test counts)?
4. #NoEstimates
Finally, as an honorable mention, there is the whole #NoEstimates argument, which has been popular in software development circles. Basically, the approach claims that:
There is a lot of scope uncertainty for most of a software project, often more than the first half of the overall schedule (i.e. >50% scope variation)
Making estimates takes time and therefore is expensive, particularly if there are tight deadlines and high costs of delay
Estimates don't contribute explicit value to final customers (i.e. they are about internal company operations and for planning purposes only)
Holding the team accountable to time estimates means that they are incentivized to sacrifice other aspects of the work, such as lowering quality or accruing technical debt, which isn't visible but with material consequences
There a number of other nuances. Basically for any knowledge work where there are a lot of dependencies (like in software), you might be better off not messing around with estimating at all. Just get on with the work.
Personally, I think estimation sessions are useful mostly for the purpose of having a priori how I'd do this discussions. #NoEstimates throws the baby out with the bathwater.
Also, by their very nature, most tasks on a large project will take different amounts of time (assuming we don't take the approach from #3 above). And technical people are the best placed to figure that out and share it with everyone. They have a unique and often common perspective, which the rest of the company lacks.
The team doesn't work in a vacuum. So timing becomes important, if not critical, to getting the full value of the efforts being made.
Doesn't all this estimation just mean there is less time to do the actual work?
This concern boils down to one of efficiency. Usually, the asker assumes that the time to complete something this fixed and that the team's primary goal is squeeze out as much as output as they can in that time frame.
In practice, though, effectiveness trumps efficiency. There is not point in doing something quickly, if it doesn't need to be done at all. To use the old Steven Covey analogy, is the ladder leaning against the right wall?
Photographer: Marc Schiele | Source: Unsplash | Is the ladder leaning agains the right wall?
And for better or worse, product teams of 2 or more people have exactly this problem. In addition to coordinating work among everyone. New product development is fraught with uncertainty, including technical uncertainty in many cases. So what the team investigates, validates, and builds in what order is critical. While efficiency is a concern, any time spent on making the new product development more efficient is likely to be thrown away if the goal changes. So efficiency won't matter in that case anyway.
Case study: Distributed estimation
A pretty common trope nowadays is that larger companies have distributed teams, often across many locations and time zones. In the early days of agile, it was quite difficult to estimate under these conditions. A lot of the nuance and genuine discussion required was simply lost in the ether. And until recently, the tooling for distributed work didn't exist. Well, that's changed.
At most client sites, there will already be some kind of story tracking system in place such as Jira or Trello. It is possible to add a "story points" field to the template for a story. Typically, this involves speaking with the owner or local administrator of this system, but is relatively straightforward.
We don't actually need any more functionality in the story tracking system. It's nice to be able to display the story points where relevant afterwards. Jira, for example, has quite useful reporting based on story point estimates right out of the box. Trello has addons. Other agile management systems presumably have the same.
On a typical planning sessions, the product owner or business analyst (BA) spins up a session of planitpoker.com. One of the nice features of this system is that it doesn't require you to set up an account or even really authenticate. Once a 'room' is set up, the BA shares out the link to everyone estimating. Everyone can sign onto the board without setting up an account.
At that point, typically I am sharing my screen with either the description of the story or any relevant collateral such as a spreadsheet, a miro board, or showing and explaining why the current version is missing a feature. I enter the story tracking id into planitpoker.com after we've discussed what it is. And then everyone votes on the number of story points to estimate the complexity of the task. Once this is complete for everyone, we look at the distribution of votes. If it's wide, we discuss and vote again. We keep doing the same until it's pretty much the same across the team. If for example, we decide that a particular story is a 5 story point size, we just type in that value into Jira or Trello.
You don't need any fancy or even paid plugins to do this. It's enough to be able to share your screen and have a discussion with everyone involved. In terms of estimation, the heavy lifting is done using planitpoker.com. Once a round of planning poker finishes, it can be discarded. And then you type in the estimates in the story tracking system, where you need them later.
When stumbling onto this approach, I think the key learning was that you don't actually need everything to be done in your main story tracking system. All you really need to do is have a good debate, and then store the outcome of the estimation. And the conversations you have while estimating are the most important art of the process anyway.
Case study: use T-Shirts for first cut of backlog estimation, then translate to story points
In this scenario, we had a large team, a massive scope, and a lot of uncertainty around exactly how the product would work. I felt we just needed to get started on the work in order to reduce the technical uncertainty behind the work. So forcing the whole team to spend hours or days estimating something they don't understand would have been a waste of everyone's time. If they started the work, we could have more meaningful estimation discussions later. For context, this was an infrastructure project.
The architect involved had put together a big graph in draw.io for how the entire system would work. It had rapidly become a symbol in the company of something highly complicated that nobody, except for him, actually understood. What didn't help was that developers in the company didn't have much experience with cloud technology. And it was relatively new stuff, even for him.
Steps taken:
Put together a vizualization or map of the scope which needs to be built, which was particularly necessary here given that we needed to build infrastructure.
We listed out the ~47 different pieces of work, most of them mapping to components of the big drawo.io microservice cloud to a spreadsheet.
As the architect felt uncomfortable assigning story points given the level of uncertainty, I asked him to use TShirt sizing for all 47 items.
If you need to do this yourself, start with what you think is average and assign them all an M. Compare everything else to those items, i.e. this is a little smaller so it's an S, whereas this is really minor so it's an XXS.
Given all of the above are sized, map the TShirt sizes to Fibonnaci sequence numbers. For example, XXS is a 1. XS is a 2. And so on.
Then use those numbers as story points and continue planning from there.
Using this slightly circuitous route, we got to a story point estimate which I felt was accurate. It wasn't precise,but that was acceptable at this stage. And the development team got started quickly on the work.
Case Study: Estimating roadmap items (to appease overachieving stakeholders)
Sometimes there is pressure to plan out a big roadmap up front for a new product. The justification that I often here, is that we want to know when "we're done". Personally, I don't feel knowing that is actually useful, especially from a business perspective. What I'd prefer to focus on is getting to first revenue and profitability. Estimating something a few years out in detail--when you barely understand it--is just a waste of time. And likely to be inaccurate.
All that said, it's useful to know your options for the future, and to also have some idea how much effort adding any given option will take. At a high level, that is probably good enough.
To keep everyone happy, the simplest approach is to use TShirt sizing of Epics. Some things are relatively small and quick. Some are huge. Some are in-between. The development team are the best judges of that, since they will need to do the work.
Clearly the TShirts for epics (groups of stories) will not be equivalent to TShirts used for stories. If you are pressed to translate the epic TShirts into story points, I'd suggest provided a range estimate for each one. For example, an M size epic is 6-10 weeks. Range estimates can still be used for planning, but aren't explicit commitments to deliver on a specific day. And they're good enough to identify if you know up front if you'll be late.
Some estimation is better than nothing at all. It's useful to just do a quick pass without going into all of the minute detail when brainstorming a roadmap. And T-Shirt epics give you the flexbility to do just that.
Case study: Nitty-gritty technical estimation in person
Geek out time, analog style. In one office! This experience, as well as similar ones, convinced me that estimating in person works best...if you can swing it. Fly people in if you have to. :)
In the early days of when I was a developer, my team and I inherited a codebase in C++ of 17 different components. Most of them were written using Borland C++, a compiler that was once cutting edge but had since largely fallen out of mainstream use. In addition to the compiler, the code used a lot of abstractions specific to using libraries shipped with the compiler. We decided that we need to get into a more up-to-date environment, to take advantage of the significant performance gains in newer compilers and also so that it would be easier to work with (and probably recruit more help for).
With an architect and another developer, we booked a small meeting room for half a day, to plan out the work. First we talked about what needed to be done. As we discussed each story, we wrote them down on index cards. We stuck them on the table, because we wanted to see all of them at once.
Then, to estimate, the work we also went analog. Essentially, we took the business cards of a former colleague who'd left the company, and wrote the Fibonacci sequence on the back of a handful cards. Then each of us took a set of the cards. We started discussing each index card, one by one. We each used one card to indicate how many story points worth of complexity lied behind each task, laying it face down on the table. Then we flipped over the cards. If there was a difference in the numbers, we got into technical discussions to convince each other that the story was simpler or harder than we expected.
After a few hours of this estimation boiler room, we had a lot of questions about one particular component which we didn't know that well. So we waltzed back to our desks to spend the afternoon looking at the existing code, and to inform our estimates even further. Finally, the next day we reconvened and finished off the complete estimation session for the entire piece of work.
Once we had the aggregate story point estimate, we provided internal company stakeholders a relatively narrow elapsed time range estimate based on how long our story points typically took. This gave them enough information to be able to plan around our efforts, especially the pessimistic estimate. The range estimate was also intentionally not precise, even though we did feel it was accurate at the time.
In practice, the estimate was correct, although the route to get there was kind of roundabout. Most of the tasks we did involved making a breaking change to the code in the new compiler. Then cleaning up the errors and warnings which resulted. The lists of problems were quite long, but then often making one fix suddenly fixed 30 errors in one go. So in short, we couldn't have really known this up front anyway.
But the estimate was close enough to be useful for planning purposes.
Key takeaways
You don't need to do the estimation in your main workflow system; you just need to keep track of the estimates there.
TShirt sizes can be mapped to story points if needed. This helps overcome resistance or speed up the process if people are uncomfortable.
You can estimate stories or epics at different levels of resolution. If you want more accurate estimates, you need to invest more time.
At the brainstorming stage, you can get something useful with a light touch estimate involving one or two senior technical people.
At an operational stage, more precise estimates help adjust the plan, but they also help everyone on the team understand the work and implicitly get their buy-in on the approach to be taken.
Invitation
If you'd like to get early access to my upcoming book on improving velocity to get to market faster with your new product, sign up here.
Following up on the slightly longer analysis of overfocussing on output and velocity, I think there are a few things that are overlooked with a pure velocity based model. Most of them have been known for decades in the software industry. They are squishy.
It's essentially a Taylorist factory where most of the interest is in efficiency, and not on outcomes. by Taylorist, I mean Frederick Winslow Taylor. In fact, Kanban originally came from manufacturing. Cost accounting is the beginning of the imposition of a Taylorist model, to describe something more nuanced than what you see in a factory. (please comment and say why if you disagree). By using velocity as a yardstick, you pervert velocity's purpose and dilute its usefulness.
As per PeopleWareby Tom DeMarco in 1987, most new technology development problems are actually people problems, either on the product development team, or with respect to the customers.
Outputs are assumed to be linear. This is patently not true for knowledge work. Even in 1975 at the time of the Mythical Man Month, it was already acknowledged that adding people tactically is a major blunder in the context of creative work.
More recently, I've fascinated by psychological safety in the team as articulated by Amy Edmonson as an underlying factor influencing actual performance.
At its core, companies care about being able to release quickly. Velocity and story points are just one way to get at what's happening and why it's taking so long. But it's essentially an internal process. At some level, it's just bureaucracy created to manage product creation...on its own usually not valuable to customers.. So in and of themselves, if the teams provide value and can show they are doing so, then velocity doesn't matter.
Manage risk. Despite having backlogs, Agile doesn't manage risks--explicitly. In 2007, Paul Kedrosky noticed a rather peculiar ratio. The ratio of software developers to non-developers at a major quant fund versus a major software company:
Oracle (56,000 empl.) -- 1:8 (one developer for every eight employees)
It's not too much of a stretch to say that hedge funds are a new type of Software Company. After all, they have more developers per capita than the latter, and they generate more cash flow per capita, if they are any good. Hedge funds also provide a fantastic template for how software companies and projects could be run. Risk management separates the men from the boys. Well-run hedge funds make financial decisions quickly, consistently with the spirit of the agile manifesto. They cannot afford to let any bureaucracy get in the way of “high gamma” execution.
In fact, a hedge fund is just a company too, with the main difference being that they have a disproportionately large pool of capital to invest in the markets. As a thought experiment, I explore hedge fund approach to investing to new software projects, specifically to compare a waterfall approach to an agile approach. All software investment projects have embedded real options. Many analytical tools exist when investing with options, and many of them are surprisingly relevant in a new product development context.
Every greenfield software development project, from the moment it's just an idea discussed by the team, is a bet on what clients or prospects want. Even if the project is being custom made-to-order for one client, it's possible the client's actual needs will be verbalized differently, once he sees a prototype. In addition to technology unknowns, development projects also face a number of other unknowns, especially in the context of marketing. Who exactly will need it? What problem will it solve for them? How many potential users exist? How do we effectively find and convince the potential users to buy this software once it exists? That's why it's reasonably easy to understand new product development as a bet the product team makes.
Copyright: Copyright 2007
Don't make detailed assumptions about the distant future.
Like tax returns, project plans in software development are largely intricate works of fiction, i.e. based on a true story. Instead, you can make supremely detailed tactical short-term plans, where:
your context doesn't have time to change as much
you can integrate your product development as quickly as possible with paying customers
you can prove that a market exists for the new product, and that the concept is even viable
You are trying to discover an unmet need in the market which your prospects will be crazy about. Then, you actually have a chance that your bet will turn into a Demarco Project B. Then you will be thinking like hedge fund, really understanding and calculating the value of your immediate real options.
In this case, you are investing in a real call option. You have a small initial outflow at the beginning of the project, to generate a minimum viable product. Your losses are limited to that outlay. Your net present value (NPV) will be negative. Based on the standard criterion for accepting an investment project, you should reject such a project if the NPV is less than 0. Nevertheless, within a few iterations, you may generate a product that starts generating revenue. This revenue stream may exhibit exponential growth. In financial option terminology, the real call option has high gamma.
What does this mean for you operationally?
If you are using an Agile approach, you already keep track of your call options in a product backlog. A product backlog is an ordered list of potential features, or user stories, for a product. In the context of a new product, the product backlog's most important function is to help you, as the product/business owner, prioritize this list, primarily based on the expected payoffs of adding a feature. Once you finish enough of a product that you can sell it, you start getting a lot of feedback about everything but the development process, so it would be ideal to have the flexibility to adapt to market conditions.
This list, while it may look rather dull, is potentially revenue-generating magic in the future. In fact, you can view it as a list of real call options, like the exchange traded derivatives variety. A backlog is effectively a portfolio of real options. An option portfolio is more dynamic. Its value depends on your business context. A number of interesting implications come out of this new model.
In fact, this is where Agile and Scrum metaphors around the backlog as a “feature idea inventory” break down for me. Typically, the product backlog is described as an inventory of potential features, where they are hoarded and stored. In my mind, a warehousing metaphor is somewhat lifeless and static. You don’t take into account the potential features’ value, when doing NPV financial analysis.
After getting an understanding of the market where a company operates, VCs just calculate a “fudge factor”, as a proxy for how much they believe the company will actually generate revenue. They use the denominator to override the value of the company’s real options on the product backlog. The value of these options will effectively decide whether the project will be a Demarco Project A or Project B, yet they aren’t taken into account explicitly at all.
In a high-tech environment like IT startups, return on investment (ROI) is more likely to be driven from adding new revenue streams than from controlling costs and budgeting. From an income statement point of view, the top line (revenues) is much more important than the bottom line (net profits), because we work in such a young and rapidly expanding industry. You can use NPV to trace cash flows down to combinations and series of tasks, and to estimate when you might be able to start selling in the future. Alternatively, you can also explicitly value your backlog items as real options. This way, you keep track of one list of fully developed features you need, so that you can prioritize much more dynamically-as you start selling and getting market feedback.
As a result of taking into account these dynamic scenarios, you have a much more accurate project valuation, at any point in time after the first calculation period used for the estimation! Moreover, NPV on its own systematically underestimates the value of most software and internet R&D projects, because it ignores embedded call options in the product backlog, which typically have high values in a volatile industry. If you calculated their value, and added it to the NPV cash flows you estimated, you can then use the NPV criterion of being net position with more precision. You will be taking into account the true value of what you get, when you invest in that project.
This is the key business difference between agile and waterfall. Waterfall handcuffs you into making estimates of a long term NPV, without explicitly allowing for optionality. Thinking about a product backlog as a portfolio of options is a much finer-grained approach to risk management, particularly when combined with software demos at the end of iterations. Then, you can legitimately claim you run your software project portfolio like a hedge fund manager.
Statistician E.P. Box quipped, "All models are wrong, some are useful". I would add that some models are more useful than others.
Miyamoto Musashi was a legendary renaissance samurai poet and painter. He invented the technique of fencing with two swords. According to legend, he won over 60 sword fight duels. He was so talented, that he killed an adult samurai with a wooden sword at the age of 13. He single-handedly fought of an ambush wrought by a samurai school. Personally, he fought in 6 wars.
Musashi Miyamoto on velocity
These Rambo-esque legends weren't his greatest contribution, though. On his deathbed, he penned a treatise on strategy called "A Book of Five Rings". As he had the ability to kill of so many opponents in duels (i.e. being on the right side of 60 duels), he became a master of the psychology of battle strategy. The book contains his insights into how he thought about this process.
“Whatever the way, the master of strategy does not appear fast….Of course, slowness is bad. Really skillful people never get out of time, and are always deliberate, and never appear busy.” Some people can cover 120 miles a day without breaking a sweat. Others will look tired within a minute of starting to run.
What's really at stake here?
How you feel about urgency and speed is a reflection of your habits in a personal context. If you have bad time management habits personally, then of course you will feel discomfort about time going by. And the opposite is also true. If you have good habits and you live in accordance with your priorities, you look forward to time passing. It works in your favor.
Photographer: Form | Source: Unsplash | Aiming for the above with my stretching routine
I can definitely see this when I do my daily stretching routine. Even though I might not be happy with the point where I started, if I do my stretches every day, my flexibility increases. And I see progress over time. So I look forwards to time passing, because if I have increasingly better results.
This observation is fractal. In a professional context, it's about the quality of your company's systems. If you have well thought through and optimized systems, you look forwards to achieving your goals. Time feels like it's on your side. The competition isn't as important as the stopwatch. Like in a road race. If you have poor systems, you're constantly harried and monitoring and firefighting. And there's no time to do anything longer term.
Photographer: Robert Anasch | Source: Unsplash | Time is on your side if your company has well thought out systems.
If I can extend the metaphor a bit to building shareholder value, particularly in software companies or in knowledge work: "Wealth is built with time as an asset, not as a liability".
Toms Blodnieks is the COO & Head of Product and Business Development at DeskTime. During five years at DeskTime, he’s helped the company grow and expand. Toms’ interests include marketing, sales, customer experience, user experience, and SaaS products. He’s a time management expert and paranoid planner who likes to plan everything and every day – from small things to large projects. His current motto? Done is better than perfect.
Welcome. Welcome. Welcome to the managing remote teams podcast. Today. We are speaking with Tom's blogs and Tom is the COO and head of product and business development at desk time. And during his time at desk time, he's helped the company grow and expand. And he's interested in marketing sales, CX, UX, and SAS products. And. I'd like to start actually with a question around your current motto done is better than perfect. What does that mean for.
Hi. Yeah. Thank you for having me on the podcast. Happy to talk about these topics. Don is better than perfect is because there are a lot of things that we want to do, how we want to build the software or webpage or whatever we do.
And we always want to do more and more. I'm getting perfect out there, The perfect just takes too much time. And it's probably too late, so let's get out the MVP. Let's get done it so people can see, so we can get the first feedback, the first expressions and then we can do the next steps to get it perfect. So done is better than waiting for.
Okay. Great. Great. So one of the things that you and your team have done is a quite detailed report around around remote at the moment. Could you tell us a little bit about that project.
Yeah the project itself this is a time tracking tool.
We offer time management, time tracking, attendance tracking project, and cost tracking for businesses, for freelancers, for everyone who needs. So we have a lot of data. And so desk is in business for more than 10 years now. So almost more, actually more than half a million people.
Actually the end users have used desk time at this point. Time to time. Take these data out and make researches. And our content team likes to write about actually. What's happening in the world and relevant data and the remote work or hybrid work and all the COVID data and how the like the breaks, the working habits have changed and stuff like that.
This is last few years, a huge topic that are marketing and content team is dealing with searching for data and checking out the countries, most productive countries. How. Everything is changing, but that specific research that probably you're talking about, which was published in earlier this year on Forbes is just showing that Comparing previous years with remote time. We see that remote workers work more. And it's it's not 10% more. It's even more like it's at least one hour per day, more than regular office or hybrid worker. In weekly basis, it's at least five, six hours more than regular worker per month. It's even almost 30 hours more. It all goes to burnout and it all goes to unhealthy work style. So you don't take proper breaks during your day, or you just work later in the evening. So you lose connection with family, with outside habits and stuff like that. That's one of the topics that we talk about that's one of the options or issues. Why desk time is useful or any other time tracking time management tool for businesses for freelancers why you need to look. At your timings, how you work. When you work, how much you work and how often do you take breaks? Do you like live healthy life and the life is not about work only.
So yeah, work is very important of course to earn money, to grow and learn and do business. But a lot of things to do outside the working hours. So we sleep eight hours, we work eight hours. And then rest of the 10 things that we need to do, we need to do in only the eight hours we have left in the day.
So how can we do that? So it's very important to manage the time correctly.
How do you define good work life balance versus what you're seeing now. Let's start there before digging more into specifically burnout.
Yeah, from our findings and from our experience and interviews that we can tell that the work life balance in first case is that you have freedom somehow the flexibility to do things that you as a human need to do. And again, this is also one of the things that we do at desk time.
And we like that. We can take our two hours, half a day off if we need to go and do something with our kids, or we need to go to the doctor or we have some kind of family issues or something, and we can do that. And then the flexibility and the time tracking gives us option. Also for our managers or team members that everyone knows where we are, how much time we have worked, what how we done.
And that's all there with data. Not only saying yes, I'm working. And I have done everything, but really there is evidence and data, that proof of work, which is very important. Because we all want to be honest for each other and then tool, like DeskTime gives that opportunity and that's yeah, good work life balance starts with that.
How do you think about it as a, as a manager, in terms of the people that you work with? Do you have any kind of expectations or guidelines around when is too much? For example?
Yeah, of course. Each company is different. So in our case in our team in our company, we have agreed on several terms that for example how many hours we actually need to work.
Like this is also one of the, part of the work life balance in our team, we. Expect to work 35 hours a week. So we don't ask for 40 hours. We don't ask to be at work like eight and a half or nine hours. We just want that there is clear working hours, seven hours a day, 35 hours a week. The flexibility, the work life balance also gives you option to work less some days and then work more in some other days.
But. That's too much would be if you work like only two days 17 hours a day. You have, in two days you have worked like those 35 hours and then the rest of the week you take off, this would be too much. Yeah. But in a normal basis we work like average seven hours a day. Then you can be flexible.
You can come at work later, like until 11, for example, In the morning and then you can work later in the evening and take the midday off and stuff like that. So you can manage your time yourself, but if you will be needed during the daytime from 10 to four, for example we will schedule a meeting like in, in a, in advance, of course if you have a calendar open and there is really no strict busy time.
So such options we have agreed how we work and give a lot of flexibility and freedom for employees. So they can really have good work life balance in their lives and be happy at work. They can, they're more effective than working during the working hours. They're more happier.
And yeah and families are happy.
And it works. Yeah. Do you have any internal guidelines or agreements in terms of meetings? Like meetings versus other types of work? Cause I think that especially initially was a difficult point for people new to remote work at the beginning of the pandemic.
Yeah. Yeah. We have talked about that. We have teams and each team lead our manager of the team. We have biweekly meetings with those with our, so with our CEO and we talk over all the uh, Logistical things that we need. And that includes also how many meetings we have.
Every week we have all hands meeting with all our staff and we publicly show the data of desk time. What time has taken for which project client thing, and one of the projects we call it is meetings. And we always see how much time we take in the meetings. And then there are like expectations and that's.
Managers. Yes, they would, they will have more meetings than like regular teammate. And but also we see that meetings don't take more than 30% of the weekly time. So this is for manager, it's a good result. And yeah that's what we. Doing so trying not to have too much meetings, but also if we need a meeting, then we do that.
If it's really, but we try to follow the, that we have agenda for the meeting and we try to do as short as possible, as precise as possible. And then we write notes in the end of the meeting to understand what we have gained from this meeting and what are action steps. So in this case when we think like that about the meetings it's quite okay.
And the timing seems to be okay as well. That 30% of the time in meetings comparing what I have read and see in in similar or other companies that. 70%, 60%, even 90% for some weeks in the meetings. I think it's crazy. There's no option. You can manage those meetings and not even any other work outside the meetings.
yeah, exactly. Do in your. Tool or in your company, do you have a way of tracking or do you track something like like energy levels of people who are involved and how that maps to, to the time being used out of curiosity.
Yeah, the energy level is nice approach. We haven't done that.
We are thinking about how to really get some AI into our system because now it's more based on real actual work by the. Mouse keyboard like video calls, audio calls typing writing and an office workers more So we don't have any like energy levels that we could, somehow that people could rate how they feel or stuff like that.
And then we have some kind of report showing that after six hours people rate they're like feeling already worked out yeah that's something we are thinking in the future about to adding and. Getting more data from like humans. But yeah, at the moment we are like comparing the time, actually work.
Then we have like automatic timers that are tracking how we work automatically. Then there is a manual timer we can turn on when we need like to do some kind of brainstorming more and then irregular work. And then of course, if we have any meetings, then we have integrations with calendars.
So they get the information from calendar to desk time. And then we see that all the overview in reports how many calendar meetings we have been, how long how many brainstormings and how many automated time tracking and stuff like that. So everything is then all together in one system, getting all the data together.
From your point of view, as a executive or say from, for, or from a point of view of a senior manager, do you then see aggregated data and you're able to see trends within the company or are your clients able to see that, that level of data.
Yeah. Yeah, I'm sure that's something that we are always like listening to our clients customers how they're using the data, what what they like and what they want to see more or detailed or what's too much. And what's easy to understand. There are some things that really been used and are very popular to, for example, divide programs, webpage applications, everything that we do in productive, unproductive, and neutral statuses.
So they like to see that how much actually time we spend productively, for example they follow what's been doing and updating the statuses. What's productive. What's not for team. And I know that companies are using also that they. To get gain the productive time, for example.
So they set less hours per day, but as a productive time like we are, we ourselves, we have just seven hours working. That's our like KPI for a day or 35 hours a week. Other ones like to look at the effectiveness percentage. So effectiveness percentage again. Indicates how much productive time versus working hours have been done.
So you can set different working hours per each, for each day and then the effectiveness percentage shows you the, how much you have done from that. And then our recommended effectiveness percentage is 80, 85%, which is very good then. And then yeah, that's some so different metrics that Users are using
In terms of speaking of effectiveness, in terms of comparing how people spend their time relative to say a high level outcome or a goal is there ways of tracking that or is that just on a, let's say a project let's say or something like that, that you track within desk time?
How does that. Yeah, you it's it's again, it's there is a possibility to follow details if you want, and if you need those details for, I don't know, client billing or something, and yeah, there is a project task client based options that you can track. And also you can see an overview of that time and then you can see details what have been done if I'm working with client a, so what I have done for that and then I can give specifics.
Just jumping back a little bit to a comparison you made at the top of the conversation. Other than the increased volume of time people are spending in front of a computer working. Are there any other interesting data points that you've noticed in terms of comparisons of how people were working before march, 2020? And let's say, now?
Yeah there's really a huge blog in our website where I don't know, like three, four, or even more blogs per week writing about different articles and data is one of the top articles that we are analyzing. So it's maybe, I don't know, at the moment, all of the.
Key metrics and the analysis, but some of some points that following, yes, this is the remote work how it's been changed and the other one, which is well recognized and very interesting statistics is about breaks . And if we see that The previous study, which was like much earlier than the COVID hit, but it was made five years ago.
About people, the most productive people, how they work at that time, it was that people like to work 52 minutes, like average at the computer and then taking 17 minutes break by average. So that was one pattern we saw from those who have the most productive hours percentage effectiveness. The average data was and now when we after the first wave of the COVID, when there was a complete lockdown and really most of the people worked remotely we see totally like different data. Working hours from 52 minutes have grown to hundred and 12 minutes, which is almost two times more.
So they, they didn't step away from the computer for twice as much time. But what's the worst thing is that the break from 17 minutes have raised only to 26 minutes. So they have worked almost two times more at the computer, but the break wasn't two times more. That's compares a relate to, to the remote work that everyone just works more.
And then takes less breaks shorter breaks. And which is not healthy. We have made videos with like sport doctors that really talks about how often do you need to take, break what you need to do at the break?
And no one of them says that it's healthy to work almost two hours nonstop and with such short break. The data are out there. , each of the customers can see the data for their specific teams or the whole organization and take actions and really react. So someone is like, Keeping eye on how much hours nonstop or in general working someone is taking action on how much time is spent on meetings.
With this 112 minutes Still roughly the same level of let's say effectiveness where it's productive work or is it all kinds of things has the overall effectiveness gone down at that time?
Yeah. I think I don't have the data at the, in front of me at the moment, but yeah, that's a very interesting question that if they're like being productive because one, one other what I remember now, if you ask this is about overtime about overtime. It's interesting seeing that for each teammate mostly there is some kind of hour.
You need to work per day. So an overtime is what you work more than those hours per day. And what is interesting the study and the data shows that if you work over time, and then more overtime, you go that less productive, less effective. You are you start Like changing the applications.
You don't use the productive applications anymore. You take more breaks then. And then the time in overtime is really not structured and not productive, not effective, not the overtime is like the, I think the article was the overtime is killing or something about like that. So yeah, that's something as well.
We try to educate our users. Short overtime is okay. Occasionally very is okay. But constant overtime is not it's bad for business. Bad for humans.
Yeah, definitely. Send me a link. I'll happy to include it in the show notes. Just so people wanna check it out.
Yeah. Sure.
Thank you.
Let's dig a little bit deeper specifically into burnout. What would you, in, in the data, how would you be seeing it or defining it? Of let's say individuals when they're at a point where it does look like they're burned out, literally?
There are some things that as I, I like to say that desktop time data is.
Like the part of the statistics or data that helps you talk to people and only desk time data is not like fully relevant to analyze and make decisions only based on data . So we need take other things combined with desk time data. And one of those is like for at least.
Last few years everyone is talking about managers about teams that you have to have a one on one meeting with your manager. So this is the time when you. Talk a little bit more, not only work related things, but also as a people, as a human as a as how you feel, how you do, and then you definitely see the differences.
If there is any, if there are any changes, time to time, and then you can. Get the desktop data and analyze. Did he work more, did he like work less? Did he had less or more productive or effectiveness or something and you see those changes of habits or something and That's how you can manage the, and see also the burnout
clearly of desk time data. Of course, it's not possible to see the burnout without any AI or as you mentioned marks of energy or something because people are different. And I like to work a lot as well. Of course. It's not good. I know, but and my family sometimes are not happy, but. At least, I feel that I'm not burning out, but just, I like to work more.
So there are people who can work more and they easily 10, 11, 12 hours per day, and that's fine. And they recharge during the weekend, for example and there are people that the seven hours are limit and they, if they work more than seven hours per day, that's there, like in few months there will be in chair with the psychologist or something. So we need to take this HR aspect as well and not only the data driven the data is something that shows and helps, but you need to have this human approach as well. To understand.
Yeah, of course. The data's only part of the picture and if anything, only with diagnosis.
So basically what you're saying is that if there's changes over time, that are concerning, that would be how you'd figure it out from what you see there.
Yeah. That's one of the options, for example. Okay.
Yeah. I'm asking partially both from a, how do you look at a person, but also if you can see whether it spreads to teams cuz A an old episode of of this podcast actually talked with a guy named Jules Turner, where he was saying that quite often, if there is burnout it's not just the one person it's often somewhat systemic, at least at the team level, if not even further, potentially. Would you be able to see a whole team kind of drifting in a bad direction? Or is that not something that you would expect to see in in, in data that you're collecting?
No, definitely. I think it's possible to see actually we have a personal experience with that in our team as well.
We were so focused and wanted to finish one of the features we related earlier this year. So we saw an increase of hours working. We saw an increase of meetings and and then talking to those people, it was clearly understandable that they are in stress that they want to finish as well.
They feel that management is asking and wanting to finish in time and That's clearly saw was possible to see from data. The 10 times are changing the different times and also talking to those people, seeing them in the office. Getting feedback it approved, this is not going too good.
It's yeah. So yeah, definitely. It's possible and it was team wise. Yeah, definitely. So it was a team wise not tell me the one person.
For managers in this kind of a situation, what's worked for you, what kind of I guess advice would you give in terms of in terms of what to do in this kind of a situation?
No. Like the situation how to resolve that it's quite easy. I think most important and is to see that something is going bad. Something is going wrong in in, in, in good timing. Because if you see that only in six months or once a year, when you do annual some kind of screening review.
Yeah. Or reviews or something it's too late, but with help of data of time tracking and then everything we saw that. Like first month was okay. We saw that indication then the second month was that we see, it's never, it's not stopping that we need to talk over. So we did that in less than 60 days and not waiting for 360 days.
I think that's the most important part, but how to deal with that then? Yeah. You need to take the what's the situation. In our case, it was a development project. And the development team was that what was involved, how we just went through the deadlines, went through the expectations and everything and, or we do the MVP, what we need to do.
Changes on that, or we extend the deadlines or we change the scope in some other way. So there are different options and then need to look at specific case. But the most important when you see the problem to act right right away, basically when you diagnose it interest.
Interesting.
Interesting. So out of curiosity, when you have like entire companies using desk time is who's typically the person that, that that kind of makes it happen within a client company?
Yeah that's a good question. We just have renewed our personas, which is very, which are very important to understand who is your.
Client which, who is your buying person? And yeah, it's still showing that we know our industries that mostly this can be used by it industries, different kind of companies in it, it sector marketing and advertising agencies are using a lot. And HR HR C. Who is that who initiates or buys is depending on the company size?
So if it's a small company, then usually the whole company is using the tool for everyone to be equal. And that's usually one of the top executives Who's making that decision also testing together with the team and deciding. But if we are looking at the larger companies from hundred to thousand people companies, which are medium company, medium size big companies there are team leads who are looking for those.
So there is specifically maybe development team is the one who initiates that we would like, and we need the time management or project management or. Something then we are finding that and then offering, and then slowly upgrading to other teams in the company as well and growing like that. But so yeah the team leads and time to time, there are HR people which are like, I think yesterday or two days ago, I had the meeting with one company that their HR indicated that they would need to like time tracking something that because the executives didn't know exactly what time, how much time and when their employees are working they've been, they're giving a lot of flexibility to come less to their office and going home earlier and then working from home and, or.
To avoid the traffic and stuff like that. And then they said that, yeah, they just need the proof of work. That everything is fine, that everything is doing their project. And if they see that some kind of project is not going as smooth as it needed or was predicted, then they can take a look if the time spent on that project at all or something or less than planned or something. And those are the data that we can see with any like different kind of modern technologies. And I like the era we are living in that a lot of things can be done. And then with the help of technology, HR technologies, HR weeks tools for hiring that I appreciate the communication tools, the video calls, the webinar tools like great,
yeah. Yeah. And I'm curious how these implementations go from the point of view of the employees. What's the typical way that it that it works when you do have a rollout and I guess at a team level or at a company level?
Yeah. Yeah, of course. That's very important. That's Depends if the executive or the team lead has talking with the team before decision of testing out tools.
And it's very important to give the instructions to explain why we are doing that. What are the outcomes we are? We want to see and correctly implement with correct settings, because for, in our case we have a lot of features that like half of the teams are not using different details of how we spend our time and.
for them. It's not needed. So for them, those who it's not needed. So do the communication the right way that they understand that this will not U be used for us. This will be turned off and we will follow the projects the client time so we can bill correctly, or we can we can manage our proof of work or we can manage the clocking clock.
With a reason why it's really needed and explaining that that, that is important. So we help as our side as well, of course, with with emails, with educational materials. But we can't be next to that executive or team lead who decides to do that and put the words in, in their mouths.
Correct way. And explain, because this is yeah it's like serious for it's. Maybe it's maybe easier for slack or any other tools that are clear that we are for communication. Although I know that's Microsoft teams are used to also to see and follow the green light to your, that indicators.
Yeah. Your online or not. So that's not the way it's probably meant to use, but
slack has it too.
oh yeah, actually. Yeah. Yeah. And then, yeah. So for example, I have like different example of different company that is using a car GPS systems and they really are helping for people to automate their reports of fueling how much gas they use.
And and then kilometers miles they drive and stuff like that. They don't need to write themselves anymore and then put their reports. Everything is. But of course it can be used as a car tracker as well, which is not good way to do that and which employees don't like. So it's very important to explain and educate how we will use and get the trust from employees, from the teams as well.
Of course.
Great. Thanks Tom. This has been a blast. Thank you for sharing all of your data and your insights and your wisdom with us.
And what's the best place for people to, to visit, to find out more?
Definitely. If you are interested in data, was it best pen dot slash blog? That's where we write and post our blogs. Of course we share everything and all the information and statistics in Facebook, Twitter, LinkedIn our CEO is actively active member of Forbes council.
So follow there as well, but all of the desk time. People, mostly I think are in LinkedIn and open to talk, open to connect. So me as well find me on LinkedIn and let's get together. Let's do some podcast webinars contents, data. Yeah. Happy to talk and then share.
Dan Pupius is CEO and Co-founder of Range, communication software that empower and strengthen teams, built specifically for the needs of the modern workplace. He has an MA in Industrial Design from Sheffield University, and a BSc in Artificial Intelligence from The University of Manchester. In past lives he raced snowboards, jumped out of planes, and lived in the jungle.
Jean Hsu
Jean Hsu is the Vice President of Engineering at Range. Prior to Range, she built product and engineering teams at Google, Pulse, and Medium, and co-founded Co Leadership, a leadership development company for engineers and other tech leaders. She’s also a co-actively trained coach and has coached engineers, tech leads, managers, VPs of Engineering, and CTOs. She loves to play ultimate frisbee and lives in Berkeley with her partner and two kids.
get three months of range for free with coupon code MRT2022 which you can apply at checkout
In his first book, Code and Other Laws of Cyberspace, Lawrence Lessig suggests that our behavior is regulated by four main forces: law, social norms, market forces and architecture.
Video interview
Transcript
[00:00:00] Jean: my team is all introverts. How do I, how do I get them to engage in these meetings?
They don't say anything. So I just call on them, which of course increases the anxiety of going to these remote meetings that you're going to be called on to, to, share your opinion at any given point. And so we do a lot of things. Like we have built into range meetings.
We have a spinner and so it shows everyone. And then, we have a check-in round where you spend the spinner and then everyone gets a chance to share how they're doing. If we were discussing a topic and it's a few people, if I notice that no one's saying anything, sometimes I'll set a timer and say Hey, I'm going to give you two minutes.
Just think about this question. And then we'll use the spinner to go around the room and everyone will share, what was surprising or any insights you had. And I find that puts a lot of introverts more at ease, where they have a little bit of time to think about it before responding. And they know that they're going to have to respond. It's pretty mind blowing. How many insights, really good insights come out of that where people might not willingly volunteer them if you were just like anyone have anything to share, but if they know they're going to get called on they'll think of what they want to share.
[00:01:05] Luke:Welcome. Welcome. Welcome to the managing remote teams podcast. Today, I am super excited to be speaking with the team from range.co I've got Dan Pupius and Jean Hsu, the CEO and CTO, respectively. Let's start a little bit with range itself, what is it exactly that inspired you to build this kind of a system, Dan?
[00:01:55] Dan: So first off, thanks for having us it's good to be here and the important topic, especially given the state of the world today. So fundamentally today range is a set of integrated communication tools that empower and strengthen teams. So we've built it specifically for the needs of today's world.
So work is more complex. Teams are more distributed and people are seeing more purpose, seeking, more purpose in their work so that some of the underlying principles. And at the core is a product that allows for teams through asynchronous check-ins. So it's a little bit like you're a virtual standup.
We integrate with all the tools. So it's really easy to see your work and what you've got done. And then we have integrated team building components, which help build a sense of belonging and connection throughout that ACS process. Around that basically at its core, we have a synchronous meeting, facilitation tools goal set setting, and then a team directory.
So really we're building a suite for remote work.
[00:02:45] Luke:When was the first moment that you started building something like this? Just in terms of timeline? Is it directly after the pandemic started or...
[00:02:56] Dan: so we founded the company quite a while ago. So as some background, Jean, I worked at medium along with my co-founder Jen.
So Jean and I were engineering and Jen was in people ops. And at that time, we were experimenting with alternative ways of managing the company, shall we say? And we saw the opportunity for tooling. So we actually had some internal engineers working on some tools to help us coordinate. And that was really like where we started having this idea of Winston Churchill said, “we shape the buildings, and afterwards they shape us”.
So if we build the software thereafter, the software shapes us, like what would it look like to build a new class of software specifically designed to encourage the behaviors that we think are important in today's workplaces. So that became the impetus for range. And we started in 2017 and. Product and customer discovery.
We had early traction with remote teams and then since the pandemic, obviously everyone's going remote and the value prop of remote oriented tooling has become very clear to everyone.
[00:03:48] Luke:Yeah, I have to say the least. Sure. Come March, 2020 how did things look as things started to, heat up for you, I would assume?
[00:03:57] Dan: Jean, you joined after the pandemic, right? Thanks for remembering.
[00:04:00] Jean:Yeah, I joined in the summer. Very different. From what I've heard from you, pre pandemic, early days of range of oh, is this a market? Some skepticism, I think after the pandemic and ever after everyone went remote, it was like, oh, clearly this is a huge pain point. Like team alignment and team communication tools for remote teams. And yeah, I joined, I think at the summer of 2020.
[00:04:21] Dan: That's all right. And the peak.
Yeah. So in pre pandemic, we had customers we'd been taking a lean approach. So we had, we've been working with development partners since day one, essentially. We had big names like Twitter quite early on yeah, like Gina alluded to while I was like religion for people who saw the need for something like this, who cared about culture and cared about productivity and engagement and belonging, it wasn't a widely held belief and it was a bit of an uphill battle.
But when everyone was forced into this remote world and many of them hadn't been remote before just like the pain was just the amplified. So the need for a new way of working a new way of coordinating was much more.
[00:04:55] Luke:You guys mentioned alignment specifically, so which of the features, most dig into that or what, what seems to help the most?
Is it the the goal setting or is it the async check-ins how do you think about that?
[00:05:07] Dan: So async check-ins is really the core. And if you think about what alignment means, it's not just about. It's not just a, like a cognitive thing of like information.
That's a feeling like we all feel aligned, right? So it's feeling like you're in the same boat. So checking in creates a habit, it's a rhythm. We have these culture building components, which help you actually feel like a team. So even if you're working on disparate work streams, you can, you feel like you're all contributing to a greater whole, and then it provides visibility into the work that's going on, which helps you understand how your work fits into the bigger picture.
And then the goal setting is a bit more about the north star and helping have a sense of purpose and tying your day-to-day work to an organizational objective. And even when, in many companies who are doing okay hours or, high-level goal setting is often very hard to connect day-to-day work to that goal.
So, range is designed to make that easier.
[00:05:55] Jean:I think a lot of times people think of the work getting done and then the connectedness and the feeling of being on a team of separate things. And so they'll have project management tools and that's where the work gets done. And then they'll okay.
Every quarter I'd be like, oh, we need to do something team building related and then, pay an external party to run a, cooking event or something over zoom. They're like, okay, we check the box. Like we did the team building or the kind of social connectedness part for this quarter can we get budget for next quarter?
And I think the unique part about range is it's all integrated. So you do your async check-in and then you answer your team building question that then you can go ahead and read everyone's answers.
[00:06:32] Luke:So what about the decision-making component of alignment? Like group decision-making? Is that, is that when the teams go and define their north star metric or how do you see customers doing that?
[00:06:46] Dan: Yeah, I think it's a good question. I think the way we think about Ranger's role in that is about building the foundation. So about building foundational context of what work is happening and what needs are emerging in the organization, but then also the foundational relationships. So imagine you're in an office you come up the elevator site your day, you make eye contact with Jean across the office.
You go over to the. The coffee kitchen, make a coffee and have a chat with someone, all these little moments these really informal ad hoc belonging cues is the term. And they're just a way of reinforcing the relationship. So range takes over some of the responsibility of those belonging cues which helps you believe that you're on the same side, you're on the same team.
And that you're like in the same tribe. Based the human instincts. So then when you go into these situations of having to make a decision or have a, a synchronous conversation over video chat to discuss some nuanced strategy, you have that foundation. Whereas if you come in cold it's just very hard to get into the flow and into the creative state, if you're feeling disconnected and essentially unsafe from a psychological point of view.
[00:07:43] Jean:I think people often think that that sense of belonging. Much the kind of default to thinking that, okay, remote teams, it's much harder to build that you need to spend time in person. I think one thing we've seen is that's not always necessarily true. Like we, we ask the team building question every Monday. That's like, how are you? How was your weekend?
And you can upload images. And so we get to see like pictures of people's picnics, their living rooms that they're painting, just like all the things they've been doing that. Share broadly with a team if you were in an in-person office. And we're doing that with such intentionality.
And we also get to see, of course people's pets and kids, and all sorts of more personal elements of our lives. I'm on zoom as well.
[00:08:24] Dan: Yeah, I think the worst version of remote workers it's incredibly sterile. You're isolated, you're alone. The only interactions you have with other humans are transactional.
Approve this tickets, or assign this this task and that's not going to lead you to make good creative, good decisions. Either you're not going to get the most out of people. That's fine if you're running a factory, but within creative work, which requires novelty and inspiration.
So we think a lot about how do we create the conditions where you can actually have these like higher functioning interaction.
[00:08:54] Luke:So what about working with developers? In terms of I guess these queues and in particular, this connection, I think because I, myself am pretty much an introvert. I think a lot of developers also tend to tend more in that into that direction. How how do you get that in ways that it doesn't feel let's say imposed but at the same time, people do feel like they can join in?
[00:09:23] Jean:Yeah. We find that the async elements really do speak to people who. It may not be in an in-person office, the loudest person in the room.
Like having async check-ins where you can add more context about how you're doing. We also do a lot of optional game times, things like that, where you can join, but if your head's down in something, you don't have to join or a lot of like audio only syncs. So a lot of different ways to cater to people who have different preferences. I'm a pretty extreme introvert as well. And so like, almost all my one-on-ones are like audio only, or I'll go for a walk. And I actually find that it helps me pay attention to what people are saying more than just I have to look straight at the screen because this person is like, expecting me to be paying attention.
Not having to worry about what I'm, what facial expression I'm making.
[00:10:07] Dan: Yeah, I'm also massively introverted. And I think the thing that we don't realize is that introverts still want human connection. It's just difficult. And so how do we make it easier for them? And early on, actually we saw, we did some studies where people self identifying as introvert versus extrovert and the introverts engaged more on the the team-building features that extroverts and the hypothesis was that the extroverts have their social needs fulfilled elsewhere because they're able to seek it intentionally, whereas the introverts don't have as many opportunities to, to find this connection. So they, we're creating this easier way of connecting actually.
So I think it actually speaks well to a developer audience.
[00:10:44] Jean:The way that we run meetings also really is well-liked by introverts, because I think when I've been running these like effective meeting sessions, and one thing that people often bring up is oh, my team is all introverts. How do I, how do I get them to engage in these meetings?
And they'll say they don't say anything. So I just call on them, which of course increases the anxiety of going to these remote meetings that you're going to be called on to, to, share your opinion at any given point. And so we do a lot of things. Like we have built into range meetings.
We have a spinner and so it shows everyone. And then, we have a check-in round where you spend the spinner and then everyone gets a chance to share how they're doing. If we were discussing a topic and it's a few people, if I noticethat no one'ssaying anything, sometimes I'll set a timer and say Hey, I'm going to give you two minutes.
Just think about this question. And then we'll use the spinner to go around the room and everyone will share, what was surprising or any insights you had. And I find that puts a lot of introverts, more at ease, where they have a little bit of time to think about it before responding.
And they know that they're going to have to respond. It's pretty mind blowing. How many insights, really good insights come out of that where people might not willingly volunteer them if you were just like anyone have anything to share, but if they know they're going to get called on they'll think of what they want to share.
[00:11:56] Dan: Yeah. I think also creating other opportunities to surface things you want to talk about. So that's another power of async is that it allows people to engage in the, on a timeframe that's comfortable for them. So if they think of a meeting topic, ahead of the meeting, or even after the meeting to bring to the next one, that's that should be totally fine.
You don't have to be on the spot thinking like, what should I talk about? Because some people in that context, it's just they freeze. It's like deer in the headlights. Really speaking to different types of communication and also information processing. Some people prefer to go away and think about things and come back 24 hours later with a feedback.
So how do we build organizations where we actually cater to all these different types of types of people?
[00:12:31] Luke:Dan, you mentioned experiments. What was what was your approach? Was it more kind of structured customer development? Was it surveys?
Was it, how were you, or were you going about doing that out of curiosity?
[00:12:42] Dan: Yeah. Early on it was it was it was all of the above. And we had a psychology advisor, so she was an organizational psychologist who who worked with us. Obviously, you're working with companies with their consent and understanding.
We would look at some of the data that they were sharing and what insights could we take away from that. And there's some pretty cool things that came out of it, which we haven't productized yet, but in the future it would be really awesome to revisit. Cause I think. Wait, when an organizational psychologist goes into a company they tend to do surveys people.
So self-reported, and it's very time-consuming. So what we found is some of the data range could provide insights in a very short amount of time that, would take multiple hours of interviews. And then we just did, did a lot of user feedback and user testing.
So to be clear, the tools that we're building at medium was very different to range. It was the principles that were interesting. It was that the software provides architecture and that architecture can support organizational behaviors.
In an organization Lawrence Lessig talks about this actually in I think it's the new Chicago school of economics. But that behavior is motivated by forces of laws, norms markets and architecture, and in modern workplaces. So many of our behaviors or norms like named channels in slack this way, send an email on Monday.
With the reports, don't do this, do that. And it's really hard for people to remember it. It's really hard to onboard and it's really hard to sustain. So if you think of software as a type of architecture, that can actually facilitate behaviors, you can make lives a lot easier for everyone and make organizational behaviors more resilient.
So that was like one of the key takeaways. So we had a team directory that made it very easy for people to reallocate their time. So I'm spend 20% on this project this month. And that made it very easy for Jean and I as like managers to know what people are working on. So I think that was like the key takeaway and that filters into the range of products.
[00:14:29] Jean:When we were working at medium together, we were in the office, but it's really important to have a place people can go to learn about people when they're working remotely cause you don't get to be like, oh, that's the person I see across the office. Now, I need to ask them for something for this project I'm working on.
Let me, they, I they've smiled at me a few times, so I know that they're a friendly person. So actually when Dan and I were still at Google we actually had probably the counterexample to the type of interactions we're trying to build where like I had been trying. Get some code committed into the code base that Dan was a tech lead for.
And I think I was probably one year Gmail, front end. And I was on a separate team was trying to work on a Gmail lab that I had started. I don't remember exactly the interaction, but I think it was just purely through code review where Dan had, it was probably fielding a lot of external teams trying to put code in the Gmail code base.
And I think he said something, just like probably slightly negative. And I remember telling my coworker that I wanted to TP his office. Cause I was like, so offended by this negative interaction we had, that was completely async I didn't know what he looked like. I didn't know anything about him.
I guess we think of remote work as like the last two years, but teams were working remotely. He was probably. We were on the same campus. We were just like, probably a few buildings apart and just like never interacted in person. Building some of that positive sentiment, like async foundation of trust so that, when things like this happen, you have some sense of.
Oh, this is like a human with a life outside of work and probably has a reasonable reason for responding the way they did, which is just, it's just a very funny beginning to our working together because now it's vastly different.
[00:16:07] Dan: Yeah. Yeah. I think that's like a, an important lesson there, which is, it goes to this transactional state of work.
And like for me, I was just getting all these change requests. And the only context I had in the change request was an LDAP name. And the LDAP name didn't seem human to me. So I would be requests in a very transactional way. And, we were getting inundated. Tons of people wanting to integrate with Gmail and it was causing some like technical debt issues.
So I was probably like shutting it down quite quickly, but over my time at Google actually, I started using, we had an internal team directory at Google. So when I get a code review from someone, I would go off to the team directory actually look at them, see their photo with the, some of the history. And it would like humanize them a bit more.
And then I'd come back and I'd actually be much more reasonable and friendly. So it wasn't, I wasn't intentionally being mean. It's just, I was I'm curious. That was before or after we had that. I think it was much later. Yeah, I was when I was on Google plus I was on the infrastructure team. We had 400 people contributing to our codes code base.
So we were defending the code base against 400 seemingly random people. And that sets you up for a lot of conflict, like us and them. So by humanizing people through the tools, and I think slack did this really well early on, you can actually change some of how you interact with people because know, you humanize the recipient and then that can increase the level of discourse.
So in range, profile photos, everywhere people's moods you can hover over and see like some backgrounds, Wednesday, birthday, what their pronouns like, where do they live? All this, seemingly superficial context that has nothing to do with work is really important in helping frame the conversation.
[00:17:38] Jean:Yeah. And Luke, you're asking about and engineers and who I tend to be more introverted. And I I think it's especially important for engineers because if you just default to like code reviews, right? Like code reviews are super transactional. Usually it's, people think that their main job is to point out the things that are wrong, but like very rarely do you get comments like, Hey, you did a really great job on this code change. Like this section looks great, right? Like you just get the kind of what could be better? And so I think without some intentional, like positive sentiment building, it can be pretty, pretty hard to be like, oh, this person really doesn't like me.
Or this is so challenging.
[00:18:14] Dan: Code reviews is another good example that can often go off the rails for many reasons. And when we think about coders, architecture github pull request templates are really valuable, right? So we have one which nudges you to. Like, why are you making this change? Why should the review of starts? Are there any tickets are excellent and contexts that they should be aware of? And then we have a funny one, which is a gift of how does this change make you feel? Actually, you can divert some of the things that often go wrong with pull requests of like, why the hell are you making this change? I don't understand. I don't have any context about this change. And then also just make, adding a bit of fun to it as well.
[00:18:49] Luke:So speaking of context, how. How do your customers use range to build context as they're going about, their team interactions?
[00:19:00] Dan: Jean, You said about how you use range to manage, maybe that's like a good example.
Yeah. Yeah, I guess I start my day in range. I share my plan. So I'm not a very like getting things done. Like I don't have a separate to do list. So I use range as my, what I'm going to do that day. And then it's nice. Cause then it's communicated externally.
And then by the afternoon, when I'm feeling in a slump, then I can just check on what I said, I would do that morning and kind of get back to it. But then after I check it. See what everyone else has said. Maybe later once everyone has checked in, first I'll see all their answers to the team question, which today was like, how are you, how is your weekends?
I get to see how everyone's weekend was. We can also really easily see everyone's main focus for the day. And that'll give me a bit of ambient context. If I know oh, this engineer is working through this one feature usually people will. Integrate or bring in the they'll attach their, like a asana ticket to the check-in and then they'll add some context of hoping to get this done today.
So that makes my job easier. So as we're planning for next week or next cycle, I don't have to go around to every engineer and say, Hey, what's the status on this thing? Feel like I'm nagging them or micromanaging them. Every other Thursday, I sit down with the product manager and designer and we are able to piece together from like range check-ins like where everyone is on their projects. And then that makes it easy for us to plan for the next cycle.
[00:20:24] Jean:Thenwe also have team dashboard where, because everyone checks in with their mood every day. So green being like good to go, yellow being like a little bit iffy and red is pretty much like I'm in crisis.
So we can see over time a two week period of the team's mood trends. And if half the team's yellow and a few reds here or there. That's not great. And so I'll, check in with people during one-on-ones maybe bring it up in a team meeting of Hey, is it the work or is it external stuff either way?
Let's figure out how we can alleviate some of the pressure, maybe think about cutting scope or moving out a deadline further. So that's one of the most useful things that I use kind of day to day with range.
[00:21:04] Luke:Mostly JIRA, I think yeah, JIRA, slack of fuse different, like speaking of async check-ins I remember I had tried a M for awhile, tried a kind of a slack bot to do stand ups or something, but the thing that was missing, actually what you brought up Gina was really interesting. The thing that was missing for me was first of all, the relationship of what the person wrote in the daily stand up to their daily goal.
And then also how that maps to what the group was doing or trying to achieve. And that's we tried for a while, just completely canceling stand-ups and doing it only async, but then that was the kind of weak spot let's say, right?
[00:21:47] Jean:Yeah. What I've heard from teams who do that is Usually that all gets funneled into like a slack channel.
And that's just like this black hole where no one reads it. Everyone just puts in there. You know what I did yesterday, what I'm planning to do. And then it just no response, no reactions. And that kind of defeats the purpose of a standup where you feel. That's a good opportunity for you to tell people they're blocked, but if they never read your check-in like that's, they're not going to know that you're blocked.
And range has something that's called flags. And so you can flag when you're blocked or if there's things that need discussion and that those things can bumped up for higher visibility. So like they just don't get lost and then you can also slice it to see okay, let me see check-ins for everyone on this team.
Or, everyone that I work with. And sometimes I'll look at the whole team, rather the whole company, rather than just the team you can depending on what you're looking for, you can look at different views.
[00:22:36] Dan: So tools like JIRA and Asana, definitely essential. And they're great for building a backlog and kind of understanding where you are in the grand scheme of things, but it's pretty hard to get a sense of in the moment what's happening and what's changing and what's stuck.
It doesn't really show you that Delta. And if you think about what happens in a standup it's often you get that data point every day, I'm working on ticket 451 then, and then you're sensing in the background. Wait a second. Is that it's not the third day in a row that they're working on this ticket and then you have to make the meaning of that was just this person that stuck.
And that doesn't need to happen in. Like in person either, that can happen asynchronously. So range really surfaces the sort of the deltas and the, and how work is changing and moving through these phases. And then there's a lot of work that happens outside Jira. So you have calendar events, you may be doing interviews.
There's Google docs, confluence. Work is spread over so many places. So range brings that all together. And maybe the reason that ticket isn't moving forward is this person's been sick for three days, or maybe it's that they've had a lot of interviews. So surfacing that context is really valuable for managers.
[00:23:35] Jean: I think the other thing that the stand-up slack bots don't do is they don't integrate into other tools. Like range check-ins, if you flag anything, it'll show up in the meetings. So if we have a team meeting it'll share all the flags that haven't been resolved and we can review them there.
And anything that needs to be discussed can be pulled over to the agenda. So just much more integrated. So it's not just check-ins is the side thing. And then this is where the work gets done. Like it's all part of the same system.
[00:24:01] Luke:So I guess the key thing is that it's pulling together everything really, so that at least you've got this overall view
[00:24:07] Dan: One of our the customer said they said that Jira is the place to go see the state of a project; range is get where you go to see a state of a person she says the state of a person or the team.
Yeah that's interesting, but you could maybe get an office setting a little bit, right? Go to where this team is sitting and you get a sense of oh, everyone seems really low energy. Or, someone seeming really upset, but with everyone, you don't see them unless you're in meetings.
And you really have no idea if you don't have a tool like range or some way to check in on folks async or I guess you could be in meetings all the time, which is also not great, but you wouldn't have a way to know people are having a rough day or like they just went through something really frustrating.
[00:24:47] Luke:How do you think about balancing async and sync correctly, both within your company or within the products?
[00:24:55] Dan: Don't get us wrong. We think synchronous communication is incredibly important. We just think that's historically the default. So it's more of a.
To get people to go asynchronous and synchronous is a crutch. Cause it's, it can be easy, but there's certain things where, async is going to be really slow. So anyway, there's like nuanced conversations, the nuanced discussions decision-making also like deep team building and emotional connection.
You. You can go a long way with some of the async tools, in-person is really where it's at. So we do things synchronous is important. I think the reality of the modern workplace with distributed teams and people needing flexible schedules is it's just the amount of time when you can have synchronous time is so much shorter, so you have to optimize it.
Yeah, so we, we really think about like, how can we maximize the value of that time you spend together and move everything that doesn't need to be synchronous outside that meeting.
[00:25:44] Jean:We'll often do things like say there's some company announcement, right? Dan or Jen might share something by email the more just transactional Hey, this is what's going on.
But if they think that it's something that people might have a reaction to, like I might check in with people in one-on-one so that we can just say, Hey, did you read Dan's email? Do you have any thoughts or concerns about it? And so like pairing async with more of the status update and then following up with synchrony.
Checking on people, how are they feeling? Their reactions? That can be really useful. And then then we're not spending that time in the one-on-one like sharing all the updates, like with each person, just like trying to use that synchronous time, but a bit more efficiently.
[00:26:22] Luke:Yeah. Yeah. Yeah, no, that's great. That's great. Fabulous. Do you have any particular suggestions in terms of team building? I guess you mentioned the thing the image at the beginning of the week or just team-building yourselves within your company. What works in a way that that everyone feels comfortable with.
[00:26:45] Jean:I'm pretty enthusiastic about better meetings. And I think that's one of the areas that people have gotten used to bad meetings, inefficient meetings, I'll say. And I think that could be a place where if you're a facilitator for a meeting, familiarizing yourself with the tool, setting it up using the spinner, that could be a really good place to just like immediately.
Way better experience, right? Like one half hour, one, one hour meeting where you have an opening round where you have an icebreaker or just like checking in on how people are doing and the one at the end. And then having more structure in between where you can take notes. I think that could be like, choose your worst meeting and run it on range because it'll be a night and day difference.
[00:27:27] Dan: The meta point there is that there's a lot of ways of Engaging and growing and building, but there's also many work processes that are just so poor that they are actively making people feel less engaged and less happy and more burnt out. So often removing some of those things first is probably like the best bet.
If people are in. Eight hours of meetings a week. And they're not feeling that they're worthwhile, they're not feeling listened to and not feeling engaged in those meetings. They're going to become less happy with work less connected to their colleagues. And any team building you do is waste it because it's just it's like a band-aid.
Fixing your team processes is step number one, and building a cadence of communication, getting into the rhythm. And then you can build on top of that to get better connection. Better camaraderie. Then you get a bunch of the benefits.
That's great. Just on the spinner, how exactly does it work? Do you put what the values are in there? So you can put anything you want, like people's names
it's pretty simple figured ones
or
if you imagine and it's also a bit silly, right?
It's designed to be silly. You have attendees of the meeting, which should get sync to your Google calendar. So we bring in names and photos and then it's literally, you press a button and it spins. Who's it going to stop on? So it's like the wheel of fortune. And it's probably not your work context, but And the reason is it's a bit of levity.
It stops one person going around the room and like randomly picking person. That's are you the person that's going to get left the last, every single time? Are you like super anxious about the call order. And it just, it's just a way of just making it a little bit easier to have everyone engaged and get a moment to speak.
And a lot of the evidence suggests that if you speak early on in the meeting you're more likely to speak later, so that has a bunch of positive impacts on inclusion for people of different backgrounds and personality.
It also takes the onus off the facilitator to remember who has spoken. So if you were to go around the room in a physical room, it'd be pretty straightforward, but on a zoom room, you have to keep track of who's gone. Or then sometimes people do this thing where they're like, whoever just went like call on the next person. Everyone has to keep track of who's gone and who hasn't gone. And then sometimes someone gets left out and then they, they make up stories about why they were excluded or like someone whose name is maybe a little bit difficult to pronounce, like no one calls on them. And then they're like always last and just like removes a lot of that.
[00:29:45] Luke:Yeah. Yeah. I like alphabetic basically. Get everyone on the call to just do freedom by first name.
[00:29:53] Dan: But then it's the same every time. So you got like poor Andrew and who's always ready? And zebedee, who's he's always last.
And then some of the other things we have, we know we have a topic timer, so you can make sure that overrun certain topics, you can shut them down and you can track action items and notes. As Jean said earlier, you can bring in work from the asynchronous check-ins. So you can review, essentially the review people's stand-ups or certain flagged items.
Yeah. I've been running panels with the meeting tool. I had one, one panelist who, you know, the first time she saw it and I clicked the spinner. She's whoa can we talk about how cool that spinner is? I need this for all my meetings. yeah, it's just a simple thing, like going around the room and calling on everyone, just yeah. It's just like an unnecessary piece of friction. We just removed that.
Yeah, no that's simple, but very effective.
[00:30:47] Luke:So where do you suggest people go to find out a bit more about range?
[00:30:52] Dan: So you can go to www.range.co. It's a self-serve product, so feel free to sign up. Free up to 20 users. And if you would like to try the premium .Version, happy to extend the coupon to the listeners of managing remote teams.
So we'll include the details in the show notes. Great. And then yeah, reach out and talk to our team. We're always on the intercom chat.
[00:31:14] Luke:Great. Thank you for coming to chat today and sharing your insights and talking about the platform and your journey.
So
[00:31:22] Dan: cool.
[00:31:23] Luke:It's been a blast. Great. Thank you. Thank you very much.
