Already, AI is the most transformative technology since the iPhone. And that statement may soon be a wild 

statement, given where we seem to be headed. The 

forthcoming possibility (threat?) of general intelligence

 and the wizardly powers of ChatGPT, DALL-E and the like, have reinvigorated all the old hopes and fears about sentient machines.

While many fields have already seen disruption from AI (see 

), the AI dice aren’t yet settled in the field of project management. However, industry watchers predict that AI will transform it soon. Gartner thinks that 

80 percent of project management tasks will be automated with AI by 2030

The good news? Where project management is concerned, AI forecasts as an enabling technology, not a replacing technology. What it will do—and is doing already—is allow project managers and their teams to make better, faster decisions, with far less legwork and guesswork. 

Buzzword killer: what kind of “artificial intelligence” do we mean?

“AI”, like “cloud” before it, has fast become one of those tech buzzwords that everyone uses to cover over a host of different capabilities and meanings. At a kind of wiki-level summary, we can say AI is the simulation of human intelligence with machines via computer software and algorithms. This includes things like pattern recognition, deductive reasoning and the perception of sense data. 

The other relevant term here is machine learning, technically considered a subcategory of AI, which describes algorithms trained on data to build smart models that can do all kinds of cool, complex stuff. In an attempt to minimize clumsy writing and irritating pedantry, I’m going to use “AI” and “machine learning” interchangeably.

AI has most charismatically been deployed in the form of Large Language Models (LLMs) like ChatGPT. Trained on terabytes of text data, ChatGPT has learned to understand both the meaning of textual inputs provided by humans, as well as to assign probabilistic values to the text responses it gives back.

This process of understanding patterns from vast datasets is characteristic of AI. Among other things, this enables (to borrow 

) the “fracking of information” from huge bodies of text. An LLM can summarize thousand-page documents in a matter of minutes, complete with citations.

Of course textual communication and summary matters to project management. But the core questions project managers seek to own and answer—When will this project finish? Do we have enough people? How much will it cost? etc.—aren’t answerable by combing textual data sets. This is why, though the LLM flavor of AI is useful to project management, it hasn’t (yet) risen to the level of “transformative.”

There is another significant body of data, however, that’s highly relevant to project management. That dataset is the work activity of the organization, as captured in tools like Jira and GitHub. This “work activity” includes things like how work is moving (or failing to move), where workloads are growing or shrinking, how long work takes to finish, and how all of this compares to the historical activity of past projects.

This idea of applying machine intelligence to an organization’s work activity isn’t all that different from the way professional sporting leagues have used advanced analytics to unlock team performance. The “activity” in the sporting case includes things like how successful batters are based on type pitch, or the scoring efficiency of the team when facing different defensive sets.

The opportunity for AI in the realm of project management, then, is to see what patterns can be observed, what predictions made, based on the way teams work, and what drives improvement over time.

Let’s first consider the kinds of questions project managers are expected to answer:

How long will this project take to finish? 

To answer these questions, the project manager traditionally relies on sentiment: their own, and that of their teams. The job, by and large, is to aggregate and analyze this sentiment data—via meetings, reports, chat threads, etc.—and present a unified whole of project state. 

In plainer terms, project managers wrangle informed opinions to answer the questions above. Historically, there’s been no real alternative. Given this reliance on manually collected opinion, it’s small wonder that the statistics around project failure rates are high. (Sixty-six percent, according to the 

Fortunately, this bucket-brigading of opinions and educated guesswork is already being upended by machine intelligence. The move is toward hard data, instead of sentiment and opinion alone. 

This change is better understood by some examples. Let's take a look at how a few of the primary functions of project management are (or soon will be) transformed by AI.

When project managers and other leaders decide what's involved in a project, we’re making judgements on what is achievable within the constraints of time and money.

This is a matter of educated guesses. Often we have one or two known variables: the number of people available to do the work, and/or when the work is due. The rest relies on the judgment of experienced people to decide how much work is involved, how to break it down into its logical parts, and to guess how long the parts are likely to take to finish.

From there, things get murkier still. If our collective best guesses tell us that we’re likely to break the bounds of what our time/people/money can achieve, what should we change? Add more people? Reduce scope? Both? How much, and where?

But this kind of prediction and what-if analyses are where machines excel. 

How do you throw machine learning at this particular use case? Via 

. Monte Carlo is a statistical technique used to model complex systems across a wide range of fields—traffic control, stock predictions, and nuclear reactors, to name a few. The idea is to use the law of large numbers to predict how a complex system might behave.

Monte Carlo runs scenarios using our best empirical data and knowledge of the "rules of physics" for the system at hand. By collecting results from enough randomized scenarios, we can get an idea not only of what is most likely to occur, but also visualize the range of possible outcomes.

This makes Monte Carlo tailor-made for experimenting with the size of scope, and/or the number of people available, to see how these inputs change forecast time to complete. In this case, the “empirical data” fed into the model includes the historical actual time-to-complete previous work, as automatically derived from the system where work is managed (e.g. Jira, Socratic, etc.). It’s the kind of capability that’s best understood by way of example, 

A big part of project management is understanding how many people—and who—may be available to take on new work, or to help with existing projects needing more firepower.

In a small organization, this is a relatively trivial job. You know, or can quickly assess, whether anyone has spare cycles. As organizations grow and/or become geographically spread out, however, the picture gets muddy fast.

It’s simple enough with existing, non-AI project management systems to see who has what work on their plates. The hard part is figuring out how long will that work take to finish, and when a person might start to have free cycles.

But newer, AI-driven solutions like Socratic can derive these answers automatically. This is because the systems observes, by person and project, 

the actual historical average time-to-complete work

Going forward, these kind of data further enrich scenario planning, especially as conducted via Monte Carlo simulation as described above. Now, for instance, the “empirical data” used in the simulation can incorporate how many people are due to become available, who, and when. And because the data is personalized, the model will also account for variables like new hires, whose ramp times may naturally be longer than more experienced team members.

Once projects become active, there are really only two questions stakeholders care about: “How are we progressing, and when will it be done?”

Progress alone is reasonably straightforward to show, a matter of looking at completed work (usually captured as tickets in a work system) against open work for the project in question. But this simple math of X% complete, while useful, is missing some important context.

Is our progress speeding up, or slowing down? By how much?

In other words, what we want to understand in addition to progress is our 

. If a long-running project shows as 90% complete, we can start to feel good. But if we see that our momentum—essentially, the change in work delivered versus open work—is slowing by a significant amount, we feel… less good. At that late stage of a project, we should be completing more work than we’re adding. Something is off.

What does this mean for our ideal smart work system? It would know, with every change in work state (tickets completed, new tickets added, tickets reopened, etc.) 

how the new state compares to the prior state, and what this means for our rate of work delivered

. Granted, the calculation involved here hardly requires AI. But it’s in keeping with the thematic spirit—how the right, smart data lets project managers jump from opinion gathering to problem solving.

Very much needing the power of AI is the forecasting of end dates. Where earlier we looked at how Monte Carlo simulation changes the game for planning new work, here we’re concerned with predicting when active work will finish. 

For active work, we have richer, more fine-grained effects to feed into the model. A short list of those effects might include:

The rate at which work tickets falls idle;

The number and relationship of blocked tickets;

The amount of rework involved before a ticket is completed;

The application of people with specialized skills.

These are examples of the kinds of granular or unforeseen changes that impact project finish dates. Where a human couldn’t hope to know or account for them all, a machine can easily observe and absorb them into its models. Accurate project forecasts, long the Holy Grail of project managers and business stakeholders everywhere, are an imminent reality.

In a low-data, high-sentiment world, both project managers and  stakeholders rely on a manual collection of opinions to gauge the likely outcomes of the project. Commonly, the feelings of the team are aggregated into a kind of sentiment summary: maybe color-coded along the lines of “green”, “yellow”, “red”.

Now, AI doesn’t and shouldn’t replace the perspective of managers or team members. Sentiment—informed, experienced opinion—matters. But if all a stakeholder has to go on is a color marker on a slide, the project manager should expect some… questions. Some scrutiny. What’s wanted are the hard data to answer the questions explored here. With data comes transparency, authority, and trust.

What AI “will do” to project management and planning is already happening…

, the leading investment research platform, which streamlines the information investors need to move quickly, build conviction and make better decisions to outperform the market. Ram's Data Integrity team is responsible for three key areas of Tegus solution offering including BamSEC.com, Tegus' modeling product, and Tegus' data acquisition product.

I was curious to learn how Ram approaches software engineering generally, and specifically where/how this thinking has informed his team’s work at Tegus. What stood out:

Eyeing the number of handoffs in an organization as a predictor of bottlenecks

Giving teams the autonomy to own the full delivery of their work to customers

Piggybacking on John Kotter’s concept of Big Opportunity to let people work on what naturally drives them

Orienting around good flow, and making every team member an owner of it

Thanks again to Ram for taking the time to talk!

Let’s start generally. Pretend you’ve joined a new team. What does Day 1 look like?

My motto is always: start slow, and ask lots of questions. Why do we work the way we work? Why these specific processes? What’s the history behind them? It’s really just trying to get to the deeper Why behind things. Sometimes you’ll find people may not even know why things are done the way they’re done: it’s just always been that way! 

A specific example I’ve seen of this is the build process. It’s not uncommon to find that everyone complains about the build taking 30 minutes, an hour, two hours, but nothing gets done about it, right? There’s a fear factor. The build process has become this mysterious, brittle thing that no one wants to crack open. Everyone's petrified to touch it.

And I always ask, Why? Why can't we get training on it? Why can't we expense a few days to understand our build process and to modify it to actually make it work?

You have that relatively short period to come in and be the person who knows nothing, which allows you to look more holistically at what’s going on. Before you’re consumed by whatever the legacy processes, and they just become mechanical for you.

Are there other things that draw your eye?

One is handoffs. Handoffs, to me, are like “smells.” If you have a software development team, and a DevOps team, and a test team, and a release management team… that smells a little bit to me because it signals an organization with lots of siloes and limited autonomy for each of the participating teams.

Another thing that I often look for is turnover, and how we onboard people. Do we have good onboarding processes, and do we ever exercise that muscle? I've seen teams that become stale with people who are tenured five, ten years. It sounds great, but when it’s time to bring someone new on, there’s just no feel for how to do it. The current team is so steeped in the code base and its history, they can’t even imagine what it means to get a new person up to speed.

Looking at handoffs is interesting. It’s like a risk indicator for bottlenecking, I suppose…

That’s exactly it. Handoffs are a preventer of flow. It’s just an opportunity for things to stall out, or get missed. 

It also tends to undermine autonomy. If a piece of work has to pass through five different teams’ hands on its way out the door, who really is responsible? No one team is accountable for getting it into customer hands. Each team could do their part perfectly, but maybe it still takes months to get things delivered. That also means months before you’re getting feedback from customers. It’s like each team is winning their battle, but collectively we’re losing the war.

How does this inform planning and building at Tegus?

I lead the Data Integrity team. For roadmap planning, we have what we call “DI Day.” The whole team comes into the office, and everyone pitches ideas of things they want. They make these pitches to the product manager. All these ideas end up written on a board. 

Once we’ve had a chance to get our ideas out, we then talk about the needs of the business. The product manager will give us the context for things like sales, business targets, go-to-market strategy, and so forth. And then we work to align our ideas with the go-to-market strategy. 

From there, we come up with a list of the things we want to tackle. A list of objectives, with some initial, coarse-grain sizing: small, medium, large. In our world, small is roughly two to three weeks, medium is three to six weeks, and large is six to eight weeks. 

On a quarterly basis, we also set aside what we call “engineering time.” This is time for all the work that doesn’t tie neatly to one of our quarterly objectives—tech debt, defects, etc. Some quarters we budget a fair amount of time for it; other quarters might have little or none. It just makes for a less stressful, more impactful quarter when we’ve got agreement with our product manager on how much time can go towards it.

So you have your prioritized set of quarterly objectives. What happens from there?

We follow the pull model—meaning, people are selecting objectives from the prioritized list. 

, which is something that gives a person a real sense of urgency, because you’re passionate about what this thing you’re working on will make possible. That really spoke to me, because I remember my days as an individual contributor where, if I got a chance to learn something new or to work on something I chose, my intensity and energy showed in my work.

So we want people to claim objectives based on their interests. When somebody raises a hand and says, ‘Hey, I really would like to learn more about this,’ or ‘I feel super passionate about this,’ they get to lead that objective. And while I have team leads, while I have seniors, there is no rule that says an objective has to be led by a senior. An objective has to be led by a person. And it doesn't matter your tenure. What matters is your passion for the subject.

Size-wise, we like our objectives to be no more than four weeks in duration. Because you want, again, that principle of flow. That principle of incremental. It just creates the conditions where the product manager gets to see something pretty fast. Three to four weeks is always the timeframe where she can see something real, get something tangible in her hands and say, ‘Yes’ or ‘Not there yet.’ 

What sort of data are you using to understand how work is going?

 is one of the things I look at in Socratic on a daily and weekly basis. And yes, as we start populating our objectives with tasks, I don't know how you do it, but that forecast feature is pretty accurate! Socratic has learned pretty well how the team works. 

We recently had some unplanned work crop up, so we had to go through an exercise of rebalancing some objectives from Q2 to Q3—what could we realistically get done, what would we need to push? I did that exercise in less than a minute on a live call, using Socratic’s forecast data to tell me what was possible, and how to get back on track. And then we moved on from that subject. We didn't have to go into a heavy planning session. We didn't have to have some long discussion. 

 is the other thing I look at on a weekly basis. 

Merge request (MR) time is obviously a key component of cycle time.* It can become a big interruptor of flow. If you think about an MR taking three days, for example, what's the developer going to do during those three days? The natural thing is to pick up another task. And if your average is three days, that means that maybe they're done with the second task before that MR is complete. Well now their work-in-progress (

) is two. Well, if they're still waiting, their work-in-progress is going to three. All right, where does this end? 

When we talk about how long should it take a developer to review code, we like to see something around 15 to 20 minutes. So ideally, your MRs are of a size that they can be reviewed in less than 30 minutes. Again, working incrementally as much as possible, keeping that flow going.

I like empowering development teams to be accountable for taking value to the market. I want my teams to feel accountable to good flow, and that starts with having enough autonomy over the end-to-end process. In my team we’ve created a few norms around how long it should take to ship a small feature, a small bug, and how we create flow and a continuous release cadence. We’ve found success in shipping bug fixes within a day or less, small features within a week, and projects within 3 to 6 weeks.

I want to work with product owners who have identified value for customers, and then have a group of teammates who are responsible for turning that into software. They should have the freedom and the responsibility to work with the product owner to define the idea, build it, and ship it!

 show merge time is indeed the largest chunk for teams, accounting for nearly a third of total cycle time, on average.

A conversation with Ram Bolaños, engineering manager at Tegus, on what he looks for Day 1 with any new software team, and the data that helps keep work flowing.

At the moment, you can’t swing a Schrödinger's cat without hitting some reference to AI. Such is the spooky action of ChatGPT and other LLMs. 

, we’re actually employing a different breed of AI: Monte Carlo simulation. Monte Carlo is a statistical technique used to model complex systems across a wide range of fields—traffic control, stock predictions, and nuclear reactors, to name a few. The idea is to use the 

 to predict how a complex system might behave. 

Monte Carlo runs scenarios using our best empirical data and knowledge of the "rules of physics" for the system at hand. By collecting results from enough randomized scenarios, we can get an idea not only of what is most likely to occur, but also visualize the range of 

tl;dr: Monte Carlo is tailor-made for forecasting how long software projects will take to finish. 

The basic steps and inputs of our Monte Carlo model are as follows:

 tasks with random (but representative) durations.

 (identically-skilled) people to complete the tasks.

(4) Determine the completion dates for each task.

(5) Construct a burndown chart from these dates.

; Socratic provides the rest. This includes randomly-sampled task durations based on our anonymized body of historical actuals, which is needed for step 1. 

For our public forecaster, we’ve set the number of model runs (

) to 100. The more you do, the more statistical significance you gain, but it also starts to absorb some serious compute cycles. In our own analysis, 100 runs is enough to get a reliable forecast.

A Monte Carlo model can be improved by expanding the list of effects that impact the system in question. You might start with a basic model, but iterate with finer and finer effects until you reach an arbitrary degree of accuracy. In the realm of project work and software engineering, these finer effects would be things like:

The number and relationship of blocked tasks;

The amount of rework involved before a task is completed;

Our public forecaster gives 'first order' approximations, a bit like ignoring air resistance in a physics problem. (Suffice to say, it’s wildly more advanced than any spreadsheet!) The scenario planner and advanced forecaster being built for the Socratic app will incorporate effects like those above to yield even more accurate forecasts.

So there it is. The next time someone asks how long some project might take to tackle, you can chuck the guesstimates and spreadsheets. With just a couple of simple inputs and a click, you get 

the power of Monte Carlo, backed by real-world data

Make project estimating the machine’s problem.

Who needs story points when you have Monte Carlo simulation?

What are the traits of fast, productive software engineering teams? We used data to establish some preliminary baselines and findings.

The data that follow are derived from anonymized work activity of hundreds of Socratic beta users across more than 10,000 tasks. This represents almost two full years of data, from January 2021 through September 2022.

What’s our average speed to release work? Are we getting faster or slower? Where are the bottlenecks? All of these are first questions for many software teams. Here’s what we found…

A quick word on how we determine cycle time (speed). Socratic automatically measures the elapsed calendar days from the time work starts on a task, to the time it’s completed. So, if work begins on a Monday and finishes the following Monday, the total elapsed time for that task is 7 days.

During private beta, we saw the average task cycle time was 9 days.

In analyzing the elements of cycle time, some ways to improve stand out...

The average time to merge pull requests was 2.9 days. With an average cycle time of 9 days per task, that means almost a third in wait time for tasks with code.

Tasks averaged 19.6 percent of their duration in other, non-flowing exception states such as blocked, rework, or deprioritized. This means more than half (51.9%) of the average task cycle time is spent in waiting or exception states.

To clarify how we surface this: Socratic measures flow efficiency by comparing the amount of time that work spends in a good, flowing state—that is, moving from start to finish as smoothly as possible—relative to time spent in these common exception states: deprioritized, rework, blocked, or idle.

For example, if a task takes 5 days to move from start to finish, but along the way is blocked for one day, its flow efficiency is 80 percent. Four of its five days (80%) were in a normal, flowing state, with one day (20%) in a blocked state. (Our method is described in more detail 

With a baseline for speed, we were curious to search for correlations to faster delivery. Some of what we found surprised us…

Even after removing outliers and setting minimums for the amount of work completed, there was little observable correlation between team size and the speed at which work was completed.

Software teams with smaller backlogs (30 tasks or fewer) worked significantly faster than teams with larger backlogs. Those teams completed tasks in almost half the time, with notably higher efficiency (that is, less time in exception states).

Limiting individual workloads had a significantly positive impact on cycle time. On average, a person with fewer than 14 days of work assigned to them completed their work three times faster (3x) than people with more than 14 days of work assigned.

Again, a word on what’s behind the data here. In place of estimates, Socratic generates 

a personalized average duration for every task, based on historical actuals

. To surface workload, we look at every contributor’s personal assigned work effort (in days).

Aim for 30 or fewer tasks in backlog. If need be, pick an age (e.g. 45 days) after which tasks are archived. Task that are important enough will come back around to earn priority.

Want to speed work? Wait time is low hanging fruit. To reduce merge time, try breaking pull requests into smaller units. Less time to review will also mean less reluctance to review.


How long does it take to complete work? Where are the bottlenecks? Knowing your cycle time and its components gives a benchmark to operate from—and targets to improve.



Let people finish what’s on their plates before adding more work. Less context switching, fewer frustrations over priority. Start with an individual limit of 14 days of active work at one time.

 Socratic’s private beta. Today, I’m happy to announce that Socratic is available to everyone.

In the days since, we’ve worked closely with our early users and design partners to rethink task management from the ground up—this time built around AI. The whole aim of Socratic is to provide actionable intelligence that helps teams work easier, faster, and better, without all of the usual digging and querying and spreadsheeting required by legacy task tools.

You shouldn’t have to write JQL queries.

You shouldn’t have to buy BI tools, or git analytic tools, or plugins.

You shouldn’t have to hire more headcount just to build and maintain reports.

You shouldn’t have to buy separate product planning tools to make business sense of what’s happening in your task tool.

With Socratic, you no longer have to. You can focus on building great product, and let our AI-powered intelligence show you how well you work, and why.

As you plan and build, Socratic harnesses that work activity to create a single, real-time view into health and progress for any body of work. No querying, no manual rollups, no wasted effort.

Using data to work easier, faster, better

With today’s release, we’re also publishing our Guide: 

Here, we lay out how the right kind of data—actionable, plainspoken, consequential—changes the game for software and product teams. 

We consider how the Jira-Agile industrial complex has resulted in lots of jobs for Scrum Masters and Jira architects, but somehow hasn’t made engineering’s life much easier.

If this resonates with you, if you’ve been looking for a better way, look no further. You’ve come to the right place.

, including all features, with as many team members as you like. Tell us what you think, and what you’d like to see added. See how Socratic works for you—and remember, the current intelligence in the product is just the tip of the iceberg. Our data science is unlocking new insights as I type…

The past decades have been largely about engineering automation (DevOps, etc.). This decade will be about engineering intelligence. Here’s that beginning.

How does a four-day week impact team productivity? 

Reports from companies that have made the move are light on data. There’s sentiment analysis based on surveys, which matters, but which in this case seem only to confirm common sense. People are happier with fewer hours in-office (even if the office is now at home), and feel more engaged when they’re there. 

As we considered our own move to a four-day week, we wanted data that would tell a more complete story on the effects of a shortened work week. (Data isn’t much fun if it doesn’t let you poke at longstanding beliefs about how work should be done. True whether you’re looking at 

In our case, we wanted to see how a four-day week would impact the 

three measures that say the most about engineering health

We began our experiment in October 2021. Starting that month, we implemented a four-day week. 

The most important variable in this experiment is obviously the team itself. In our case, the actual names and total team size remained consistent through the periods in question. We’re a virtual team, and remained so. We didn’t go on a hiring spree, or change our working hours, or swap junior resources for senior ones (nor vice versa).

A second key variable is the type of work performed. As a startup, we have an advantage as a control group: all of our team remained focused on the same, single offering.

Obviously, we also need a common unit of measure for work. In engineering, there are two candidates: tasks, and code. We use tasks. There are a couple of reasons for this. First, tasks, unlike code, are a unit of measure non-engineers can understand. Second, quantity—getting more done—is inarguably good where tasks are concerned. The more tasks completed, the better. (The same isn't always true of code. ”More code” may or may not be a good thing.)

What interested us was seeing how our productivity changed across:

 (or cycle time): average days to complete a task. As a component of this, we also measure average time to 

, versus exception states like rework, deprioritized, idle, blocked.

With Socratic, we get all this data out of the box.

The following shows changes in our own engineering productivity over two periods: a six-month period of five-day weeks, versus a six-month period of four-day weeks. (These periods are sub-divided into quarters, for the sake of trend granularity.)

In aggregate, the amount of work we delivered decreased by about 14 percent period over period. But the quarterly trend tells a more nuanced story. Our throughput in the first two quarters of four-day weeks actually met or exceeded throughput from the final quarter of five-day weeks.

A word on how we determine speed. Socratic automatically measures the elapsed calendar days from the time work starts on a task, to the time it’s completed. So, if work begins on a Monday and finishes the following Monday, the total elapsed time for that task is 7 days. 

 in the average number of days (5) it took us to complete a task. 

This fact may be the most surprising, since we were working one fewer day per week. With a day less day per week to do the work, we assumed an average speed of 5 days would increase to something like 7 days—you start on a Monday, but now finish the following Monday because you didn’t work Friday. Instead, our average speed remained constant.

Just as encouraging was the change in average time to merge a pull request. In the period of five-day weeks, this was just under a day. In the four-day week period, merge time decreased by roughly a third.

In brief, we measure efficiency by comparing the amount of time that work spends in a good, flowing state—that is, moving from start to finish as smoothly as possible—relative to time spent in these common exception states: deprioritized, rework, blocked, or idle. 

Here again we saw improvement, albeit small, in moving from a five-day week to four. 

With the exception of our throughput (caveated above), moving to a four-day week had either no negative impact on productivity, or coincided with improvement. This is to say nothing of the qualitative benefits we’ve experienced: a better work/life balance for our team, and a competitive edge in recruiting and retention.

In the words of one team member: “The extra day off helps me keep a better work life balance and take better care of my personal life. I'm much more focused while I'm at work than at previous jobs.” Another says, “I'm less likely to feel burnt out after the end of a work week. I get to enjoy new hobbies and activities. It was a deciding factor in choosing to work here.”

The quantitative and qualitative together made our decision an easy one. The ‘experiment’ of a 4-day work week is now permanent.

How does a four-day week impact team productivity? We looked at the data.

Jeff Bezos, you may’ve heard, felt engineering teams shouldn’t be larger than what 

So. The prevailing wisdom can be summarized as “around seven people, and no more than 10.”

This has a good, commonsense weight. Too much larger, and you can feel team cohesion requiring more attention, more work to keep people on the same page, more managerial time to see that everyone is getting the right guidance and feedback.

These are all valid reasons for keeping teams on the smaller side. But, maybe for these same reasons, there’s also a general sense that smaller teams are 

As the following data show, that ain’t necessarily the case.

To see if we could find a correlation between team size and the speed of work delivered, we studied anonymized work activity across hundreds of Socratic beta users, which represented a total body of work of over 10,000 tasks. To qualify for inclusion, a team need to have completed at least 20 tasks.

Speed, or cycle time, is the average duration (in days) to complete a task—something that Socratic surfaces automatically.

Even after removing outliers and setting minimums for the amount of work completed, there was little observable correlation between team size and the speed at which work was completed:

This lack of correlation between team size and speed may be… good news? It suggests you can set your team sizes based on what feels qualitatively right, without worrying about hitting some  tipping point, beyond which your speed will come crashing down.

There’s that old proverb: “If you want to go fast, go alone. If you want to go far, go with others

But the data say something else. You can go fast 

There’s a lot of math around ideal team size. Does it really matter?

There’s nothing quite like an awful interview—the kind where both you and the candidate leave feeling as though you’ve just barely survived a terrible first date. Done poorly, interviews can be just like bad first dates: awkward pauses, a dim feeling the other person is avoiding certain topics, confusion as to why you got together in the first place.

My aim here is to help people avoid this feeling. Maybe you’re new to interviewing software engineers, or maybe (like me) you’ve been tasked with planning the interview process for your company. Whatever the case, there’s a reasonably clear set of things to do, and things to avoid.

I learned both—the do’s as well as the don'ts—having interviewed hundreds of engineering candidates for companies like Nordstrom and Microsoft, as well as coaching hundreds of candidates for their interviews via 

From these experiences I’ve developed a pretty clear understanding of what makes for a good interview, and what makes for a terrible one!

At Socratic, we follow a three-interview progression:

The screening interview is truly introductory. I start with a run-through of what our business does, and what our tech stack is. I’ll ask the candidate to give a brief rundown of their work history and expertise. The aim here is two-fold. I want to (a) discover any areas of contention and (b) remove any doubts, from both sides.

As part of this, I ask the candidate about the kind of work they love doing, as well as the kind of work they’d rather never do again. The phrasing here matters. It’s easy to talk about what we love doing. Usually you can see passions coming to the surface, and it keeps the conversation fluid.

The dislikes are just as important of course, but I’m also interested to see how candidates convey those dislikes. Do they become irritated or resentful, recalling past lousy assignments? Did they take away anything useful, even if the work itself was a drag? How did they manage doing stuff they didn’t like?

When the candidate merits the next step, a technical interview, I also go over salary range, equity, and benefits. (Not necessary if you’ve included these in your job posting, which I recommend. But sometimes there are valid reasons to withhold.) Neither you nor the candidate wants to go through a 90-minute technical interview, only to find you’re not in the same ballpark on compensation.

The content of the technical interview varies by role and seniority, but in all cases the coding challenge should be a direct reflection of the coding done on the job. Ideally it’s a real coding example your team recently worked through.

At Socratic, for a full-stack developer, we ask them to do a front-end challenge in React and a backend challenge with some API’s (payload, routing etc.). While it’s great if a candidate can complete a challenge, that’s not the outcome that is most important. I want to understand how they work through a problem, what their process is and what they do when they hit a roadblock.

For that reason, I always ask the candidate to speak openly about their thought process, and try to engage them in a conversation as we go through the code. If they get stuck, I have no problem if they want to look up things like syntax. We all forget syntax. We all look things up. Let’s interview in a way that honestly reflects that reality.

A new kind of
task management
work intelligence

Task management meets artificial intelligence. A simple, powerful way to work better, easier, faster—from idea to working software.

Instant answers for the whole team

Answer the questions that matter.

Are our priorities on track?

Where do we spend our time?

How are we improving?

Methods

A new kind oftask managementwork intelligence