A couple of weeks back, I helped run a team building workshop for a potato seed startup in Kenya. The team was made of seven people with job titles such as agronomist, caterer and accountant, but when you asked them what they did, they had far more in common than not. Almost everyone was involved in the field activities. Everyone had marketed and sold seed. And when asked if there is anything they didn't want to do, the answer was broadly "no".

This was a team filled with passionate people who thought no role was beneath them or impossible for them. Which raised the question for me of what is the right approach to defining roles and jobs when a team is just getting started. Interestingly it reminded me of a different system design context, composition over inheritance.

Composition Over Inheritance

The idea of composition over inheritance comes from object-oriented programming. It is the idea of achieving code reuse through defining objects' properties that they share with other objects, rather than having them inherit properties from ancestors. To learn more about the programming application of this design pattern, the Wikipedia article does a good job of explaining it. The reason I bring it up is that in essence the distinction between approaches is how you define an object (has-a vs is-a) and this feels directly applicable to defining job descriptions.

While at Amazon Web Services, I found that job descriptions followed the "inheritance" model. I was a manager. I fell under the category of management and my day-to-day was largely defined by this categorisation. This approach creates uniformity, which is desirable in an organisation which values "fungible" employees. Management wants to know that they can move people around and just have them fill the gap. The problem is that this model creates calcified job descriptions that often prevent people from doing the thing that needs to be done. You are evaluated on specific metrics related to your business role and therefore going outside your role is not rewarded and can even be detrimental to your career progression.

When it comes to startups, the opposite model, "composition", is better suited to the business stage. The greatest benefit of composition is its flexibility. Creating a job from a composition of roles does two things. Firstly, it gives the person performing the job agency to determine what they are excited about and what of that overlaps with the needs of the company. Secondly, it establishes the premise that jobs are fluid and they evolve as the needs of the company and the interests of the person evolve. This flexibility is essential in startups.

Also, composition allows for and encourages lateral growth when job title or salary growth are restricted, as is commonly the case in startups. As mentioned above in my observations, employees often take on new but needed roles without being asked. Rewarding and formalising this allows you to celebrate the commitment and passion of those employees.

These discussions around roles can happen in 1:1s or in groups, but having a regular group discussion about everyone's roles will surface any unexpected roles and allow for effective distribution around the team.

Final Thoughts

This is a loose analogy, but one that I found felt natural and pleasing once I saw it. This is not a revolutionary way of seeing things, but it is helpful in understanding ways of getting a small team to cover the broadest range of roles while allowing them to grow and develop agency. Creating the discussions around roles and allowing the team to take them wherever they want to will bring the flexibility and ownership that startups so desperately need.

I remember joining my first software team and being incredibly frustrated with the lack of documentation. The team had existed for a couple of years already but documentation on how to build and develop the service was sparse. I brought this up and the response was that documentation would go out of date immediately and therefore creating it would be useless. I found this argument illogical, given that we were in the industry of building software. Our job was to create and maintain systems that are in a constant state of degradation. In essence, we were fighting entropy.

Fighting Entropy

The most visceral experience of the effect of entropy in the software engineering world is that of trying to build a package or application years after its last release. The compiler has changed; some of the dependencies are on a newer version and the old version has been pulled due to a security issue. The build fails due to a dynamic linking issue. It hurts and it is frustrating, but that is just part of the job. The package is needed, so the problem needs to be solved. You scan the logs and Google the error codes, and finally find the Stack Overflow post that solves the problem. You update the build pipeline and move on.

Yet, even though it is a similar experience when it comes to documentation, somehow it is not worth it. The reason for this is that the benefit of good documentation is not immediate, and therefore the cost/benefit analysis is skewed. In the case of software, you build it, you run it and you get the outcome you want. With documentation, you write it and then the benefit is only felt at some indeterminate later point, with faster onboarding or recovered context.

Co-Location

Often documentation is stored separately from code. Maybe there is an internal wiki or shared drive. This means that the context needs to be duplicated, once in the code and once in the documentation. Rather, create a single place for context to be stored, next to the code and then generate documentation from it. This lowers the cost and chance of the documentation going stale. The prose will still drift as the code changes, but now it is right there in front of your face and only needs to be changed in one place.

This can be implemented as a team-level process and enforced using linting. Have CI fail on undocumented interfaces or go even further and have it warn on function bodies that change without a change in comments. Though this does not cover all forms of documentation, such as architectural decisions, it is surprising how much you can store in comments. I would encourage you to push more context into this space. The benefits of co-located documentation are also more immediate. It makes reviewing the code easier, as reviewers can gain context without leaving the review. Also, AI-assisted coding benefits as the context is easier to provide to the agent.

A good example of documentation generation is cargo doc from the Rust ecosystem. Write your comments next to the code and then an HTML site is automatically generated. This is not new; Doxygen has been doing it for decades, but the tools are getting better and each modern language has its own version. For example, TypeScript has TypeDoc and Go has go doc.

Cargo doc goes even further by allowing examples to be written in comments and then tested against the code using the doctests subset of cargo test, further preventing staleness.

Do-Nothing Scripting

Another common type of documentation is runbooks, for example, a build and deploy runbook or incident debug runbook. These are important use cases for documentation, because getting something wrong or not being able to do the work has direct customer impact. There is an opportunity here to use documentation as a stepping stone to a robust, automatable system that even new team members find easy to learn and use. This further increases the benefit of good documentation.

Do-nothing scripting, from Dan Slimmon, takes these runbooks and converts them into shell scripts that at first just print the next action, but over time the script can be automated to perform the actions itself. This has a two-fold impact: it lowers the amount of manual work needed, while ensuring that the steps stay up to date. If you would like to know how to implement this for your team, you can read more on Dan's blog.

Final Thoughts

There is a lot in common between maintaining software and documentation. By using modern tooling and techniques the benefits of good documentation can be enhanced and felt immediately, just like with software. You are still just fighting entropy.

Judgment is a skill. It is learned and needs to be practised. Good decisions are not obvious when they are made; they take time and results to evaluate. Big decisions do not come along often. The combination of these facts makes developing good judgment difficult, but not impossible. You should start practising now.

Background

When I became a manager in 2024, I was promoted from a junior engineer position straight into managing a team of software engineers. There were engineers in that team with decades more experience than me, and now I needed to guide them. To make it more difficult, the team was formed out of two smaller groups and so we had not all worked together.

It felt like I was thrown in the deep end. I immediately needed to make decisions for the team, set priorities and communicate to management. This was incredibly uncomfortable; imposter syndrome was in full effect. I tried to overcome this anxiety by constantly looking for consensus within the team. All decisions became team votes and this slowed us down.

After six months, my manager surveyed the team on my performance, in preparation for my official transition. In general, the team was happy and we were performing well, but they gave consistent feedback. I was asking for too much input and not deciding for myself often enough. At first, I was happy about this critical feedback because I thought that it meant I had done the right thing and not disenfranchised the team. But I had overcorrected and hadn't given myself the opportunity to develop good judgment. So, I changed gears and with my official transition into management, I set myself the goal of developing and practising the skill.

What I Learned

Trust Is the Foundation

I did overcorrect, but I do believe that building a foundation of trust is the first step. Building trust can happen in many ways, as I describe later on, but the one direction that I did take from the beginning was acknowledging the experience and skill of my team members.

In my first 1:1s with them, I stated: 'You are here because you are a strong engineer and have the technical experience. For judgments of technical direction I will look to you to make the first suggestion.' This approach acknowledged their strength and knowledge and set the framing going forward.

As you build trust, you can move quicker. There is less need to check in and reach consensus, because team members can trust that you are making decisions with the correct amount of data and input from stakeholders.

Data and the Lack of It

Speaking of data, I like the idea of data-driven decisions, and you would have to search far and wide to find someone who doesn't. The problem is that data-driven is not a binary property. The amount of data available to you and the amount you use in the decision-making process can vary widely and for good reason. With this in mind, I have found the mental model of one-way and two-way doors to be a helpful framing.

Figure out whether the decision you are making is reversible. For example, starting the first production run of your product may use all your available capital and therefore it is an irreversible decision. Whereas, prototyping an idea using one of a couple of commoditised API services is highly reversible. Using the model, you can then aim to gain as much data as needed to understand whether it is a one-way or two-way door decision. If it is a two-way door decision, get 70% of the data you feel you need. In the case of a one-way door decision, break it down into two-way door decisions to decrease the overall risk.

Repetition and Feedback

Practising judgment requires making many decisions and having a good feedback loop to be effective. You can create a feedback loop by actively seeking feedback from stakeholders and defining which metrics you will use for evaluating success when you make the decision.

You cannot guarantee that feedback will be quick. Some decisions will take months to bear results and others in seconds. Each decision, no matter how big or small, should be used as a learning opportunity.

A high density of decisions compensates for slow per-decision feedback. The compensation is essential to ensure you are ready to make big decisions when they are required. They cannot be the only time you practise judgment.

The good news is that the lessons are broadly applicable. Did you not gather enough data, and so the decision was wrong? Did you have enough data but not communicate the decision well, leading to an incorrect implementation? Did you do everything correctly, but the dice just didn't fall your way? All of these outcomes will happen to you and more than once, so use them to make sure each time you are improving.

Practising Judgment

Commit Now

You will have already been practising judgment your whole life, but start with deliberate practice now. You need to get the reps in, which will mean that you need to make many decisions, quickly. This is uncomfortable and may cause you to make the wrong decision. This is expected and therefore you should develop mechanisms for fixing the mistakes you make. The mistakes can take an infinite number of forms, but the outcomes are easy to predict.

Build Trust by Taking Accountability

Incorrect decisions result in negative outcomes for your business (lost revenue, delays, increased costs) or for your team members (worse team culture, bad career growth opportunities). These outcomes result in one real issue; you have lost or broken trust. The amount will be dependent on the size and scope of the decision, but you will need to rebuild that trust. The good news is that making the effort to rebuild this trust is a trust-building exercise in itself, because it shows that in the future when you make mistakes you will work to make them right. This can be the first part of your mechanism, starting with self-accountability.

For example, you decide to develop the cheaper version of a product feature and the resulting version's quality is not good enough to deliver to customers. The first step in rebuilding the trust is to take accountability and acknowledge your mistake. Again, this is a skill; you need to practise it. The first time will feel terrible, but it gets better and the outcomes will be better for it. But once you have taken accountability, you can work with the team to develop a better version. With this plan you can then take accountability with your stakeholders and rebuild the trust there.

Delegate Judgment

Finally, the last part of practising good judgment is knowing when to delegate and teaching the person you delegate to good judgment. That feedback loop can only get you so far, before you are out of time in the day to gain context and make decisions. You will need to delegate eventually, so prepare for it. Offload the low-risk decisions, give others the chance to fail, and then be there to point them in the right direction when they do.

Final Thoughts

Judgment is fun. I cannot think of a better day than when I was able to make or be part of great decisions. This is something that I would have struggled to believe when I was overwhelmed with analysis paralysis in my first few months as a manager, but it is true. Go practise your judgment, think about how you can get feedback and make some mistakes.

When I first joined AWS in Berlin, I was put on a greenfield project. The team was just two people, a senior engineer and me. We had three months to deliver a new macOS-based hypervisor integrated into the EC2 Nitro platform. I was in a new country and a new organisation. Having already been at AWS for a year, I knew how hectic work could get and was determined to not burn myself out.

Quickly, we built out the hypervisor, with the senior engineer working overtime, often late into the night. He was focused on integrating the hypervisor into EC2 Nitro, and I was implementing the controller and virtual machine monitor. After three months, we were able to launch a virtual machine, but there were still open questions, specifically: how we would implement block storage and networking, since Apple's Virtualization Framework was missing key Virtio functionality.

Unfortunately, the real issue was that the senior engineer had burnt himself out. He took mental health leave, and suddenly I was the only person keeping the project moving forward. In total, I worked solo for six weeks, testing and packaging the prototype.

At the six-month mark, we delivered the prototype, but due to the missing functionality, the virtual machines did not boot up fast enough. We had run out of time and the project was shelved. Fortunately, the senior engineer recovered, but this time will always remind me that you cannot rely on crunching to get the project done, since you might just burn out long before you get anywhere close.

Issues That Will Arise

Burnout

Startups are inherently high-pressure environments where each team member feels like they need to be working as hard as possible. But with this high pace comes burnout. Burnout has a real health impact and that should be a good enough reason to try to prevent it. If you need another one, then you should consider how much you value predictability.

The success of a startup is highly uncertain because the predicted outcome is based on assumptions. The first priority of any founder is to decrease uncertainty by squashing assumptions. By assuming you and your team can push without end, you are guaranteeing that you will at some point lose yourself or one of your team for an indefinite amount of time. Maybe it is during a lull in business, but have you had any lulls since you started? Most likely it will be during a key point of delivery. This will burn the trust you are building with your team and stakeholders.

Insurmountable Blockers

When you are doing something novel, there will be technical blockers. Hopefully, you will overcome all of them, but some can't be. The reason may not be purely technical. Maybe, the solution will take too long to implement, or the trade-offs are too large, but there will be blockers that force a pivot.

There is an unfortunate Catch-22 here. If you don't push hard enough, you will burn through your runway before you hit the blocker. If you push too hard, you burn yourself out before finding a solution or an alternative to pivot to.

Sustainable Development

I believe the answer to burnout and insurmountable blockers is sustainable development: finding a pace which can be maintained indefinitely.

Re-Evaluate Your Goals

Ask your team this: can we keep going like this for another five years? If the answer is no, then you need to re-evaluate. Re-evaluation can take you in one of three directions: increased resourcing, smaller scope or delayed delivery. All of these sound like bad compromises because they are.

But, these are the best compromises you are going to get. The longer you delay making these decisions, the worse the options get. Eventually, you may not even have a decision to make, because you have run out of funding or your stakeholders have ended the relationship.

Compromise with your eyes wide open, and give your team a chance to make it the right decision.

Re-Evaluate Often

Re-evaluating your goals should not be an ad-hoc activity. It should happen often and at multiple levels of abstraction. Of course, there is a cost to stopping work and taking a step back. Therefore, you should implement mechanisms that allow you to efficiently re-evaluate your progress and effectively communicate the resulting decisions to your team and stakeholders.

For evaluating progress, there are hundreds of project management systems, and it is worth finding one that works for you and your team. Using an agile method is a great place to start.

What's often missed: you also need a mechanism for evaluating the stress level of your team, because the ratio of progress to stress is the real metric you need to monitor. I have found 1:1s the most effective mechanism for monitoring stress levels.

Final Thoughts

There are going to be many issues blocking your delivery. You are going to miss deadlines and have major setbacks. By working sustainably, you ensure that you have the energy and resources to pivot when you hit insurmountable blockers, building trust within your team and with your stakeholders along the way. Remember, there is no end in sight. If you don't work sustainably, you will never make it anywhere close to being done.

I think 1:1s are the most important meetings a team lead has. Running a team without regular 1:1s is like deploying software without alarms. You are flying blind. It is not a question of whether you will be surprised, but when.

1:1s Are Fundamental

The reason that 1:1s are so fundamental is that they provide a flexible, regular mechanism for feedback to flow upwards. Feedback is often fleeting and can cause conflict, so people don't raise it on their own.

Without a regular way to share feedback, feelings build up and can compound into resentment. For example, having a team member quit out of the blue is never a snap decision for them. You missed the build-up. Without feedback, it is incredibly hard to improve the situation. As a team lead, you will never have complete awareness of what your team is experiencing. You need this feedback.

Running Good 1:1s

At my first job, I was called the canary in the coalmine, since I would often raise issues unprompted. This bothered me. They had just outsourced their feedback channel to one person. They could rely on me, but only while I was still around. When I became a manager, I implemented the following two mechanisms to ensure that I never had to rely on a canary.

1. You Don't Own Them

The team member should own the meeting. This changes the dynamic and raises your awareness of the impact of postponing. The team member gets to decide whether the meeting is important and how often it happens. I would recommend 30 minutes, weekly, to start, but this will change as the relationship and the nature of work change. Remember, this is time you are committing to them. You can postpone, but only by asking them, and acknowledging that something important is being delayed. If you do need to cancel, you should have a plan to follow up.

Along with not owning the meeting, you don't need to own the meeting notes. Create a shared document and use it to record decisions and actions. This creates transparency and simplifies your record-keeping.

2. It Is About the Team Member

1:1s are about giving space to the team member to share their feelings, thoughts, frustrations, ambitions and anything else that may come to mind. I think the best way to ensure that this is understood is to always ask the same question to start: 'How are you doing?'

They will immediately start talking about work. It is important that you politely stop them and explain that you are actually asking how they are, not about work. It doesn't need to be long, but there needs to be an understanding that they come first here. This may feel awkward at first, but after the first couple of times, both of you will know what to expect. I find that this sets the tone for the meeting and helps team members understand that this time is for them. The emotional state of your team members is your early warning signal. Use it to prevent surprises later on.

This also normalises sharing their feelings and gives you the chance to support them emotionally, in addition to the technical and managerial support you will already be providing. You do not need to pry and do not push for details.

Closing Thoughts

1:1s can be run in an infinite number of ways, but I have found that the above two mechanisms have brought the highest return on investment. They put you on the right path: meetings your team values, and a more cohesive and productive team as a result.