When we replatformed Twill, we built a software factory: agents write most of the code, a merge queue lands it, CI decides what gets through. Which means there’s a lot of activity, and every release I cut (several a week) includes a list of changes. But I need to know if the factory is working. Are we generating impact or just endless lines of code?
I have a collection of scripts to pull and analyse our output, which I initially put together for a talk. They’ve been useful enough that I keep looking at them, so I added them to the AI dev starter kit. They cover the output and guardrail numbers below; hotfixes and CI spend come from elsewhere.
The things I think are worth paying attention to: output, reliability, and efficiency.
Output
What did we make, and what kind of work was it?
This chart shows features went from 66% of PRs to 16% while volume went up 24x, and guardrails from 12% to 36%. The scripts classify by PR title, which gave 22% guardrails for September; for this chart I ran a more detailed classification on top. Guardrails should ship as part of the work as well: in September 89% of feature PRs carried their own tests, up from 62% in April.
With just two engineers, the feature work is where we’re bottlenecked, whereas the guardrail work is more mechanical and can scale much further with orchestration.
None of this tells you what we actually shipped. That’s what the headline features are for, the same ones that go in the monthly board report. September’s feature share looks low, but actually it was fewer, bigger features – something we changed our process (adding more detailed specs) to support.
September’s included a member referral programme, marketing pages rebuilt in-app, a Chrome extension for LinkedIn referrals, and a state-of-the-business dashboard. (The extension is in another repo, so it’s not in these numbers.) For things that are internal only, like the dashboard, we shipped early and iterated aggressively with actual users, which means more fixes but also earlier feedback and usage.
Reliability
Hotfixes
Hotfixes are my primary reliability metric: how many issues were severe enough that we shipped an additional release the same day. August had about 10, around half of them in launch week. This has dropped since then, in part due to the increased number of guardrails. September had one. October also had one (already!), but that was a big change (the marketing page rebuild – a bunch of DNS and redirect updates), and I’d planned for that release to need extra attention.
Guardrails
The chart above shows the evolution of guardrails. Rules, then checks, then guards, then guards on the agent itself. They reinforce each other: “changes must have tests” was in CLAUDE.md from day one. It wasn’t reliably true until coverage was a required check. That required check doesn’t mean the tests are good, so the agent dispatch instructions now require mutation testing.
These are the kind of things that used to come out of post-incident reviews, but now they need to evolve continuously. If you’re iterating on your product with AI, you should be iterating on your guardrails too.
Efficiency
Median time a PR was open: 1.2 hours in August, 3.5 in September, partly merge-queue contention, partly DB changes (which get more attention and human review) increasing in volume and complexity. PRs landing in two commits or fewer: 67% down to 53%.
CI spend belongs here too. I have another skill (not public, too tied to our stack) that I use to check the spend is adding value. It should be increasing linearly with output, and where it’s increasing above linearly, the value should be clear.
More guardrails and more checks mean work is harder to land. That’s a trade, but with two developers incidents are extremely expensive, so keeping them low is the priority. It also means this system can’t scale indefinitely; with one or two more developers, it would need rethinking.
Engineers, we use a lot of words to talk about architecture, but at a fundamental level, I think architecture is about making good decisions easier, on a timeframe you can reason about.
→ Small startups can’t reason about a long timeframe, so architecture has limited ROI. → Banks have requirements around audit trails and – for trading systems – response times, that influence their architectural choices. → Open source projects are constrained in their choices by downstream users. → Large companies are usually constrained by long-term customers – Windows and backwards compatibility, for example.
Often architectural disagreements are less about the architecture itself, and more about what constitutes a reasonable decision. On what timeframe?
I have been working on a slide deck for the past few weeks. Using Claude Design, exporting things to PowerPoint, importing them into Google Slides, having Claude in Chrome clean up the little bits of positioning that mess up along the way. Keeping track of all the things that need to be fixed in Claude Code (where my todo list lives).
And it occurs to me that I have the same complaint now that I did years ago when I worked on the mobile app for Google Slides. A lack of proper API. Something to do with live editing had meant it made sense for everything to live in the JS layer.
Lately I think of that decision – I’m sure a reasonable one, made thoughtfully by smart people with the context and priorities they had – every time a Google Docs MCP is disappointing to me.
This, I think, is the challenge of the timeframe. The timeframe of that decision didn’t include the rise of phones and tablets and people doing real work on them – let alone MCPs.
In a startup, trying to get traction and survive, you are thinking about the immediate future, hoping that a long term will emerge. You need to be flexible, and stay flexible. Bad choices can bite you over time, but good choices can be too expensive to justify.
When we shipped the Twill replatform in 4 months, we got there by being strict about scope creep. Keep things simple. Don’t overcomplicate.
However, I did make a couple of architectural choices that were relatively expensive, but that I believe merited the effort. And that is because when we talk about making good decisions easier, and agentic development, there are some things that are really important.
The first was building a design system. It makes it easier to have rules around testing and accessibility, and ensures visual consistency.
The second one, more interesting, was a role-based access control (RBAC) model. This is something I was quite intense about, for a few reasons.
First, it’s a multi-user platform, so the same data gets viewed in different ways by different people. A member gets one view, a candidate another, a recruiter a third, etc. Being clear about who can see what is critical, and so the easier that is to reason about, the more it pays off.
Second, this is a place of churn as we figure things out. It was somewhere I thought it would be important to be able to add new types, and move things around – something that did indeed happen. I wanted it to be easy to add a new type, and one line in a table that means hasPermission() now returns true.
Third, this is a place where security considerations are front and centre, and having something tidy and easier to reason about makes those easier to enforce.
Neither of these choices would have been justifiable in a pre-agentic-development world. But in an agentic development environment, I have seen the impact in both. They are areas of high churn and potential complexity that have caused far fewer problems than you’d expect. As I noticed emergent architectural problems elsewhere, I added more work of this kind – for example moving the hand-written SQL to generated queries.
There is an argument here about how agents compress the timeline and follow patterns blindly. But I think the more interesting one is about what constitutes a reasonable decision for an agent. Humans have an unusually rich sense of time. We can relive the past and imagine our future selves – what psychologists call mental time travel – in a way few, if any, other animals can. Agents talk about time, but they don’t experience it.
Humans, we don’t just know what happened in the past; we viscerally feel the moment when the thing we could have prevented came to pass. And we care about what comes next, and the people who will live with what we build. The ability to reason about the future, and about what’s likely to change in it, is human, and as such a human responsibility.
We’re doing a big release this week for DRI Your Career. Mostly bug fixes and reliability work nobody will notice, but the two things worth mentioning:
Audio episodes are now available as a private podcast feed.
Made significant progress towards supporting multiple coaches (yes this implies some very exciting announcements – more soon).
We’ve come a long way since it was just Jean and “Claude the intern”, but mostly very iteratively. We’d come to a point where it seemed worth rethinking. We wanted to ship some bigger things – this release was nearly 100 PRs over about a week, passing back and forth between Ireland and California – and to do that we had to mature our approach.
Release branch and release process (vs pulling from main). I know this goes against conventional wisdom, but for a 2 person team with no on-call SRE, I think it’s better to be able to schedule your problems for a convenient time.
Orchestrator + merge queue. The merge queue tends to be stricter, so everything gets 2 code reviews, follow-ups filed, and so on. It also handles sequencing and rebasing – the things I used to burn CI minutes on when I was chaotically working in 5 tabs.
Board hygiene. P0/P1/P2/P3 issues, aligned with the orchestrator + merge queue setup. Everything related to features slated for the next release gets tagged so it gets prioritised.
Devex and optimisations. Ephemeral DB targets, authenticated E2E tests, env var requirements, a full design system, automated nightly DB backups.
What I find interesting is that these four pieces map onto four different phases of a team maturing.
Overkill. Slightly anal for two people. But the natural progression for a 2 person team no longer wanting to deploy main on every PR.
The AI-native piece. Only necessary because AI exists – also allows Claude to work overnight whilst we are sleeping (and don’t need the tokens for everything else we are doing).
The setup of a well-organised 6+ person team. What keeps the orchestrator (and us!) focused on impact rather than maxing out token and CI spend. Brought in when I realised we could easily ship >50 PRs but no finished headline feature.
A level I used to watch 20+ person teams struggle to reach. Necessary to support the velocity.
All of this to say that a sensible setup for a 2-person team has shifted dramatically from even a year ago. If the shift is that big for a small team running a small website on top of other activities, it’s going to be even more dramatic for larger teams. The list above is our specifics, but the categories are transferable: even if your process was right sized for your team before, it isn’t – or shouldn’t be – once each person on your team is running a team of agents.
What is your release process? How do you validate, find issues and monitor?
How do your agents run, what guard rails are in place?
How do you maximize value for token spend?
What’s your DevEx setup and how does it need to evolve?
Lately I’ve been thinking about the AI shift as upending the standard bottlenecks for team scaling. That’s moved me from “we need a new playbook” to “we need to update the existing one with different priorities”. All but one of these are things I’ve done as part of scaling a team in the before times. I just didn’t used to do them all in a week.
This is why I stay optimistic about developers even as writing code gets automated. You can’t just “AI it”: getting AI to solve problems faster than it creates them takes judgement. Claude helps enormously in moving things forward, but knowing what to prioritise and what it should be doing is a critical input.
This is the kind of work good managers do – evolving how the work gets done as the team evolves, to keep things moving. So we’ve decided, again, that we “don’t need managers”, at the exact moment there’s more of that work to do than ever… My hot take from years of experience scaling teams and being deeply immersed in AI-dev for the last 8 months or so? We’ll come back to the same conclusion – managers matter 🍿
The core problem of scaling a team is that not everyone can know everything. Scaling is the work of systematizing that – so that things are understandable, knowable. It’s turning “tribal knowledge” into documentation, automation, and process. It used to be that only the automation was for the machine, but now documentation is machine critical and process is machine readable.
With humans, things bubble up and down. You don’t – in general – make systematic fixes for the first complaint. First you validate, check the scale of the issue. You try the softer interventions – trying to get people to actually talk to their team mates – before you start building process. Maybe you make a change a month to the way a team works. Carefully, thoughtfully. Because no effective person wants to be on a team where the job seems more process than impact.
Automation was always the most effective, but also usually the most expensive. The thing that gets put in when “please follow this checklist” fails frequently and severely enough to be worthwhile. An incident can be the gift that delivers the agreement on priority that always seemed necessary to those close enough to it, by making the cost of not doing it clear.
As we are deep in replatforming Twill, I’m back to being a developer, and as I operated my orchestrator and dispatched agents on the backlog, even though in some ways everything is wildly different, some parts of it that I reached for out of habit felt very familiar: scaling.
+AI
AI feels like speed-running some of the team scaling stuff that previously I orchestrated over months – years even. The economics have shifted to make automation much cheaper, so it’s no longer deferred, but top of the list.
With people, knowledge lives in two places – in the people and in the systems. With AI, only the systems part persists. Every session starts contextless. This is the problem that surfaces all the documentation that wasn’t written, and all the automation that was never built – a core part of why building with AI from scratch is so much easier than retrofitting onto an existing setup.
On DRI, when Jean started building the platform, we talked affectionately about “intern Claude”. Over time, we matured away from that framing. We put the guardrails in. We stopped treating it as a novelty to be supervised and started treating it as a system to be designed. With Twill, I started from a higher level of understanding, and the baseline was higher.
The snark, which I’ve also expressed: people will do for a machine what they were never willing to do for their team. Write the doc. Define the work clearly. Build the guardrail. Forgive the mistake.
I stand by it. But that doesn’t mean those of us who were always trying to do this for humans gain some moral high ground by not doing this for machines.
The rigour was always good practice. The humans operating the machine will have a much better time if those machines are set up to succeed. I think the call for EMs to “get closer to the work” has been poorly expressed and executed, but at the core of it – having got much closer to the work myself – I have come to see the validity of it. The scaling problem that managers used to deal with is now happening at higher speed, and the only way to have fidelity on it is to understand the work being done. Because so far, there is no playbook – we all have to write our own.
The best example of this is CLAUDE.md. For both DRI and Twill, it’s a living team artifact, and the churn on it is a good thing – the way of working should keep evolving, as we evolve our understanding, our work, our effectiveness.
Three terminals
“Dispatch a review agent” was encoded in our process for months. It’s very helpful. But I would still find the odd issue or untracked follow up. Then, tired of Claudes colliding on CI and wasting build minutes, I made a merge queue. It serialises merges across concurrent sessions, files the follow-ups, and sends PRs back when they’re not ready.
The next round of reviews I dispatched came back clean. And the next. And the next.
Turns out merge queue Claude, reviewing work it had no part in, was stricter than the Claudes that had done the work.
The reason is the contextlessness. Which gets talked about like a strength or a weakness as we look for metaphors about working with this thing that is new and we don’t yet fully understand. I’ve given up on metaphors, and think this aspect, like this shift in general, is best treated as a neutral.
The reviewer had no investment in the work. Nothing to rationalise. No “well, I did it that way because.” It knew only what the standard said and whether the code met it.
So many times, after reading a review or finding something that didn’t work as I expected it to, I’ve thought that something should be already prevented by CLAUDE.md and asked why it wasn’t. The answer was always clarity – fair. But turns out, like humans, the answer could also be process.
The common manager refrain on AI is that it separates those who think from those who don’t. Fair. But one of the core skills you have to develop in leadership is knowing what to pay attention to and what can be ignored. The broader your scope, the more you need to be brutal.
How many times have I told someone “that’s not making it onto my list”? Too many to count. Enough that people have been known to text me when they find themselves saying it. Now, having so many things in flight at once, I’m always trying to figure out what to pay attention to and what not.
The mechanical guardrail is encoded in CLAUDE.md: hit the same issue twice, stop. A lesson learned the hard way after burning a bunch of build minutes on something stupid, because it only got intermittent attention and seemed like it should be fine. It’s inclined to keep pushing through, but telling it to stop also tells me to stop, to give that problem some attention, to think.
Before, the discipline was: you found a bug, you wrote a test so it wouldn’t come back. Good practice. Now, I do that, and then I ask: how do we guard against this class of problem?
Competent humans rarely make the same mistake twice. AI will make the same mistake endlessly.
Making a class of issue impossible is not cheap. This is why we didn’t use to do it. A minor bug spawns five-plus follow-ups – graduated solutions of increasing complexity. A null-handling issue that threw 500s; fixed in one PR, but the follow up issues to eliminate the pattern and add a tripwire in CI so it can’t come back got added to the backlog, ready to be picked up, implemented by the orchestrator as a slot becomes free. Done within the week. Because now it’s possible. It’s tractable: it’s bounded, well-defined work, which makes it exactly the kind of thing you can hand to an orchestrator and let run in parallel.
I keep reading all this stuff about “working with AI” and it’s so depressing that most of it seems to be about building things that run AI agents. What’s the point of it? What are you actually shipping? Is this just some game, like The Sims: But Make It Programming (and also really expensive)?
Cranking through a bunch of stuff to launch, I’m running Claude in three tabs. The first is an orchestrator. The second is the merge queue.
The third is the terminal where I actually define, decide, and unblock things. The most important one. In this one sometimes I feel like a product manager, sometimes an engineering manager, sometimes an architect. Sometimes I’m just wiring up secrets and things, feeling like some modern day version of the ENIAC women who used cables and switches. At least I get a manual.
Scaling a team, you keep coming back to the same need: be clearer. Clearer about what’s expected, who owns what, what good looks like. Clarity. Clarity. Clarity.
One of my coaching clients and I developed this framework to help him think about the kind of impact he wanted to have as a Staff+ engineer, and since then I’ve taken it to other clients and direct reports in a way to think about engineering growth outside of any particular job ladder.
The four growth dimensions are:
Scope
Complexity
Output
Agenda
Scope
What it means: Scope is the size of the problem or responsibility and is relatively straightforward to quantify in LOC (Lines of Code) or people involved.
For ICs, this often goes bug -> small feature -> large feature -> multi-feature project -> …
For managers it’s often TLM (Tech Lead Manager) for small team -> manage team -> manage managers -> manage managers of managers …
Failure mode: The failure mode of growing in scope is often need to control. What is possible to control in a small team or project gets progressively harder over time. Everyone reaches some kind of limit there (admittedly some much later than others).
Inflection point: Figure out how to get the outcomes you are responsible for with different mechanisms than that of control (documentation, setting standards, coaching and mentoring, reporting, pro-active checkins etc).
Opportunity: As scope changes, think about how the way in which you work needs to change. Whilst we might fix a bug using a debugger, it’s much harder to develop a complex feature like that, and so that increase in scope is an opportunity to adapt and grow. This continues as you take on more responsibility; you cannot (effectively) manage managers the way you manage ICs. It’s worth noting that sometimes in our careers we might take a decrease in scope – for example when we change jobs and have to onboard through fixing jobs, or go from managing managers to managing ICs in a smaller organization. In these instances we will also have to adjust our approach to our renewed scope in order to be effective.
Complexity
What it means: Complexity is the difficulty of the problem, and more difficult to quantify – sometimes it takes some amount of domain knowledge to know what is challenging.
For ICs complexity is in the projects, the complexity of the feature, the problem space, or the code base.
For managers complexity is in what is being delivered and how. What is being delivered is the complexity of the product, managing a team building a CRUD app is less complex than managing a team building a more specialized/unique application with a greater variety of client side work. How it is being delivered is the way in which the tean works, for instance a team that has to manage more stakeholders (such as a platform team) may have higher complexity than a product team.
Failure mode: The failure mode of complexity is the continuous increase in complexity. Effective scaling (of an individual or a team) involves the transformation of complexity, where something that was complex is made simpler in such a way that it can be more sharded.
Inflection point: Complexity is often a point where engineers around senior get stuck. Having worked with continuously increasing complexity, they either make things more complex than they need to be, or persist a high level of complexity that needs to be simplified and sharded.
Opportunity: Take a holistic view of complexity – complexity is not just the code, but also the product and environment it exists within. Focus on outcomes to resolve and reduce complexity in such a way that it allows others to be successful.
Output
What it means: Getting things done, or causing things to get done.
For ICs this starts with an initial focus on raw individual output, and progressively shifts to enabling other people over time.
For managers this is the output of your team or org, over time. Over time is important, whilst you can create short term output at the expense of things (underlying work, attrition), you will typically pay for those in the form of lower output later. This means being able to balance an increasing amount of disparate work whilst maintaining a good rate of output consistently.
Failure mode: Short term thinking. Individuals who focus on their own effectiveness at the expense of the team, managers who push short term output at the expense of longer term team functioning.
Inflection point: Recognizing when output needs to happen through other people rather than individually. Balancing short term pressures with longer term impact.
Opportunity: Take a broader view of output, identify where you can overall increase output outside your own individual efforts (through other people, via processes, tooling, architecture etc).
Agenda
What it means: The driving force of what you’re trying to get done. As you progress through an organization you will have to balance a broader agenda, ultimately driving the agenda of the entire organization, and navigating conflicts between that and the agenda of individuals or teams.
ICs often focus on their own work or team, but at Staff and above typically need to hold a larger agenda around an area or domain.
Managers need to fit the agenda of the team within the overall agenda of an organization, tying it to work that impacts the business.
Failure mode: Taking too narrow an agenda that conflicts with bigger agendas. Such as the IC who pursues their own interest at the expense of the overall team, or a manager who is too focused on the team they manage versus taking a “first team” (peer) mindset.
Inflection point: Moments of conflict between an individual or team agenda and an organizational agenda.
Opportunity: Look for places where there is an opportunity to tap into a broader agenda, whether it’s focusing on the team’s needs rather than your individual needs, or the goals of an overall initiative rather than the pressures of the project.
Making it Actionable
When working within a job ladder framework it can be a challenge to 1) separate out evaluative feedback from developmental feedback and 2) truly focus on growth rather than trying to check a box. As such, I hope this can be a neutral tool you can use to consider how you can grow, and what kind of growth would support your actual career goals. It’s fine to enjoy scope more than complexity (and vice versa), the main thing is not to allow something to hold you back by becoming a controlling weakness.
The first step is to identify one of these to actively work on, bring awareness to it, and execute on a plan to deliberately try to improve (whether through stretch assignments or deliberate practice).
The topic that got the most attention in my previous post about being the DRI of your career is the concept of rent versus buy when it comes to managing your career.
Distinguish what your employer rents versus what they buy. I find this particularly relevant when it comes to things like “personal brand”. My employer buys my time, they rent my personal brand. To that end, I’m conscious that whilst it’s part of the value I bring, I don’t want it devalued because ultimately it’s my asset for the long term. This concept also applies to expertise. My expertise is rented, and so I maintain my understanding of what it’s worth, and what is current on the open market. If your job does not match the market in a way that will make it hard for you to find another one, I hope your employer is paying a lot of rent – because they are destroying the market value. At times that might be worthwhile, but often it is not, and people realize that too late.
Here, I’ll expand a little more on how I think about that, but I’d also love your input on how you think about it and what examples you would place in each. Leave a comment, ping me on Twitter, or drop me a note.
Rent
When you “rent” something out, you retain ownership of it – the renter just gets the use of it. As the long term owner of the asset, it’s on you to be conscious of the value, and make sure the renter is not destroying the value long term.
Expertise
Expertise is a key example here. Your expertise is yours. It’s what will help you get your next job, negotiate your salary (oh hai “market value”). Because “professional development” is a core retention strategy in tech, too many people are complacent and outsource this responsibility to their current employer, instead of being strategic in how they consider their own development. This is why there’s discussion about “staying current ” as a developer. We used to hear the phrase “there are a lot of unemployed COBOL programmers”, and now it’s more like, there are a few COBOL programmers, they make a lot of money, largely from banks or the government.
This piece is often where the side project dialog goes off the rails. Should you need to do side projects to get a job? Are open source contributions a requirement? I am a hell no on both these points. However, being strategic about where you invest resources (time and money), and/or developing a habit of deliberate practice can help you develop your expertise and command a higher rent on the market. The extent of that investment is up to you.
I think developers, if they are lucky, can largely get away without thinking too critically about this, because professional development is a core retention strategy of most “good” tech companies. But at smaller companies, levels above senior developer, or in management, training is often limited and deficient, and if the individual doesn’t take control over their own growth they will hit a ceiling.
As a hiring manager, the biggest mistake that I see people making in this realm is the resume that shows “X years of experience” (where X>=6) but when you dig in you see the same 1-2 years of experience again and again. These people top out, stop getting recruiter pings and they don’t know why – but it’s because they didn’t consider how to grow their expertise as they switched (or didn’t switch) jobs.
Brand
There used to be a lot of discussion about “personal branding” and frankly it was nauseating. But, as an individual we all have a “brand” or a “profile”. At a minimum, it’s what’s on your resume, and how you build the narrative of your career. Some companies or roles are detrimental to that. If you work at a company that is materially contributing to (and profiting from) the collapse of society, that may reflect on you.
A common mistake I see is where people have a job title or custom role that does not match the market. Companies sometimes try to pay their “rent” in inflated job titles – I’m extremely skeptical about the value these have on the open market. For a good recruiter or hiring manager, a “VP” or a “Director” job title without an expected scope of responsibility opens more questions than it answers. It’s worth mapping your responsibilities to the expectations of the market periodically, and checking that you’re still generally employable – hybrid roles where people do A and B are particularly susceptible for not meeting the criteria of either A or B externally. An “and role” can be a plus when you do one thing particularly well but have additional skills – for example an engineering manager who does some product work, or a designer who also does some CSS. “And roles” where people do two+ jobs, poorly, do not set people up for success in their broader career.
But for those of us who have a bigger profile, some recognition in the community, the concept of brand goes beyond the resume. In a leadership role or DevRel, but to some extent elsewhere, your profile and ability to attract talent is part of your value to a company. It’s important to remember that you retain ownership of your profile, and that it’s for the long term. You don’t want to be seen as a shill for a company that later turns out to be problematic.
I saw a tweet lately that made me think about this; the company thought they were buying this person’s profile. But she was clear it wasn’t even available for rent.
This point on brand doesn’t apply to everyone, but where it does it’s worth considering carefully. My main point here is: boundaries. Think about how you want to use your profile, what options you want to be available to you, what boundaries you want to set around it. Make sure that you’re balancing between the rent and ongoing market value.
Attention / Context
Attention is also rented. What do I mean by that? Often you work in a particular domain, and you pick up things about it. Maybe you work in fintech and you acquire a bunch of knowledge about financial regulation. Maybe you work on web standards, and acquire a bunch of knowledge about governance. Maybe you work in Open Source and acquire a bunch of knowledge about licenses. Your attention is directed by your domain.
When you leave, you take with you that context and what you learned, and that can help you elsewhere. Personally, I’ve been working in Open Source and building remote teams for a long time – those things have had my attention, now I know a bunch of stuff about them, and that is one less thing anyone has to explain to me when I switch jobs. In another part of my life, I did a bunch of work on presentation software and picked up various things about file formats and rendering. At times, I use these bits of information. It’s like a shorthand; I can more quickly evaluate a resume, or the likely complexity of a project, because I have that domain knowledge.
The win of attention is a little additional curiosity can result in disproportionate amounts of learning given current context. Later, you have these bits of useful information that you can use to accelerate things. Being conscious of how you allocate that can make a difference and make more opportunities available – whether you go deep, or pick up complementary / adjacent contexts. The mistake of attention is when people think they know a domain, but really they know a company. I remember the interview where someone told me they were a “$domain guy” when their understanding seemed very limited to questionable business practices of one particular company which… okay yes, did have a product in that domain.
Buy
If some things are rented, what is bought?
Time
Time is the obvious one, typically part of the working agreement, officially around 40 hours per week. Some jobs are more than that for whatever reason, and should pay more as a result.
The time aspect is interesting, because research shows that in senior roles, they are more likely to be held by men, whose wives are less likely to work. Women in these roles have fewer children, and are more likely to be single (source: HBR, see also: “7 in 10 men who have enough income to put their households in the top 1% of earners have stay-at-home spouses” Qz, “Why promoted women are more likely to divorce” BBC).
What I take from this, is that the time commitment of certain roles is such that it’s extremely challenging for someone to have such a role and be a parent. Those roles are compensated highly because it’s essentially compensating for the time of two people, where one is the “worker” and the other is the person who makes that level of work possible. The US presidency is perhaps the biggest such example, and one of the interesting things about Dr Jill Biden continuing to work at her usual job as a Professor, is that the position of “FLOTUS” (the unpaid second position that comes with POTUS) has to be filled at least somewhat by people who are actually paid… themselves… to do the work.
Working in a distributed context for years, the biggest mistake people make with time is that they don’t manage it well. Some people cannot cope with the flexibility, they fail to give themselves the structure they need to be effective. The other failure mode is the opposite – people struggle to disconnect from work, overwork, and burn out (for more on this topic, see: Figuring out Remote Work is Figuring out Work).
Energy
I include energy as distinct from time, as I think it’s what explains the continual gap between the hours that people work, and the hours that people think they work (much more). My theory is that when people think about how much they work, they count the energy that they spent. When they track the time, it’s more concrete. So a long dinner with friends is definitely not counted as “work time”, but if you’ve had a shitty week and spend half of it emoting… it counts energetically.
Dysfunctional environments are an energy drain way beyond the time commitment, and typically way beyond what you are actually compensated for. Thinking about it this way is an encouragement to set boundaries, or – if they aren’t respected – draw lines (like turning the phone off, or ultimately look for another job).
Adherence
Adherence is the agreements we make as part of any employment contract. Some jobs don’t allow people to do any programming/writing/speaking externally, and this can be a lot to give up. Maybe you have to live in a certain place, work out of an office, etc. In distributed contexts, travel used to be one aspect of adherence. When hiring at my last job, we would be super clear: 49 weeks of the year, you are wherever you like. 3 weeks of the year, you need to make travel work. It wasn’t for everyone, but I think that is normal and expected; not everything is for everyone.
If your employer is buying adherence, then it needs to be reasonable. Perhaps no amount of money would make you go back to an office – totally get it, but if your employer thinks they have paid for that, you are going to have to figure a way out of that disagreement that may well involve finding a new place to work. Personally, I can’t imagine selling my ability to write and code for fun ever again, but earlier in my career I made that trade-off for a while, and paid for it later.
Trade offs
Thinking about career decisions this way, you can consider different tradeoffs and options that work best for you at any given time. As an employee, it’s typical to allocate more time, more energy, and in return typically receive higher levels of investment in expertise – this helps people grow more, and ultimately earn more over time. The benefit of different working relationships, like contracting, is often to set stricter boundaries around time and energy, which can free people up for other things (or just maximize short term income). I can’t emphasize enough that all choices are valid and that people operate from wildly different constraints, many of which perpetuate systematic inequity. My question is: are you making those choices mindfully? And do they work for the life and career you want?
Call me a cynic, but I don’t expect software estimations to be accurate. Because software is built by humans – and they take sick days, and vacations, time to help their colleagues (hopefully), have off days as well as good ones.
But I still think estimations are worth doing. Firstly, because if we don’t have some reasonable concept of how long something will take, how do we compare the effort and impact of A vs B and make any kind of rational decision?
Mainly, though, because the order of magnitude by which we are off says something about the project. We should be off by an order of magnitude smaller than the one we estimated in. I.e. when we estimate in months, we should be off by weeks. When we estimate in weeks, days.
Being off by an order of magnitude smaller allows for humanness and human error.
Being off by the same order of magnitude we estimated in suggests the project wasn’t thought through enough at the outset. It makes a case for spikes, and discussions, and architectural reviews.
Being off by an order of magnitude larger than we estimated in suggests something went truly wrong. These are the projects that drag on and on with no end in sight, and sunk costs too deep to rationally contemplate. They sap the morale of the team and destroy your reputation – internally if not externally. They are usually a sign that some bigger change is required.
Beau recently tweeted an observation I made to him, which people reacted to… Something to do with “plague animals” all “ending up dead”. And well… maybe it isn’t my best management metaphor.
It’s a metaphor for how we expand people’s comfort zones – the way we want to give people more responsibility gradually, as it feels possible.
I suspect most high achievers have a point where we go from energised to so overwhelmed by everything we grind to a halt. Keeping people (especially new managers) in the space where they are energised, and catching as they head towards overwhelm is part of the job. It’s great if people will realise it themselves and surface it, but if we haven’t built a relationship such that they feel they can bring it to us… what are they going to do?
This is the failure mode – people drown in the sea of things they have to do, with nowhere to turn.
Some people like to be thrown in the deep end to figure it out, but thinking about this metaphor I realise that people who thrive when thrown in like rats are people who have built up their own resiliency and support. They’re not really being thrown in, because they have a parachute to deploy and a support team on standby, ready to help.
Which also clarifies that part of the frog boiling is to help people develop resilience – and a support network. I tell everyone around me that when their job gets harder, they should make a friend. Coaching is also amazing for helping develop resilience (and self awareness) and I encourage everyone to take advantage of it (if they can). But as a manager, how you react to the inevitable failures of people on your team – do you react with kindness, understanding, and coaching?
Or do you do you take your broken trust out on the person, destroying the relationship between you in the process?
How do you react to your own failures? Do you display the same accountability and commitment to learn that you ask of them? Or do you embrace a double standard?
As I think more about this metaphor, I see that the art of change management is the art of frog boiling. As much as we might be tempted to throw grenades in there “for speed”, consistent temperature and stirring will yield the highest number of live, temperature resilient frogs.
One of the (many?) things my team may be tired of hearing from me is “empathy is part of our job”.
What do I mean by that? Well as mobile developers, we are the closest to the humans that use our product. We need to have empathy for our users – what do they need? What’s their experience?
For me empathy starts with a foundation of self-awareness and self-care. It’s a lot easier to consider other people’s needs when my own are being met.
Then, we can build on that with empathy for each other. If you can’t find it in you to connect on a human level with the teammate you work with every day, how do you find it in you to connect with the abstract idea of a human using your product?
What does this mean? Because honestly this phrase even for me invokes some nightmare scenarios of codependent emoting. But what I mean is the practise of seeing someone else’s perspective. Listening to each other. Valuing each other’s strengths, and not judging each other for our quirks.
We could start with a culture where we don’t blame, where instead we look at our processes and consider how they have contributed to the situation. Then, we improve our processes. Our “culture” is defined by our processes, afterall.
It’s a pyramid, and at the top is empathy for the user. We have to care about them. What they are trying to do, and in what situation, and on what device, they are trying to do it.
For me, the practise of empathy is mainly taking a moment to see the other side. But how do you do that for an abstract person? One example is that when I’m frustrated by fragmentation on Android, I remind myself that fragmentation is mainly a problem on lower-end devices, and as a result lower-income users. And then I feel a lot better about spending time on it. When I’m trying to prioritise anything to do with personal information I think about how upset I was when GMail changed my name and I couldn’t change it back and that reminds me how that would be even more upsetting for some other people.
Basically when I look at some large piece of engineering work and ask how important it is, I ask, who is it important to?
Thinking about this left me with one question – can you have empathy for the user if you don’t have empathy for your team-mates? Or, can you build a functional product without a functional team?
The conclusion I came to was that I think it’s possible, but I have never seen it. I think the answer as to why is that emotional energy is exhaustible, and if you spend it fighting for or defending yourself, there’s less of it when you need it to fight for, or defend, an abstract person you’ve never met.
Cookie Consent
We use cookies to improve your experience on our site. By using our site, you consent to cookies.
