One of the most often repeated sentiments about working in startups is that they lack structure, processes and that everything is chaotic. While this is mostly the result of urban myths in silicon-valley-driven work culture, there is some truth in it, though this is only in the very early stages and as the startup scales, some “order” will have to be imposed.
(NOTE: For the purposes of this piece, startup includes small business or team - I recognize they are all distinct terms but here they will be treated as functionally the same)
Working in a startup will have you putting on a variety of hats at different stages in the delivery of some tangible outcome. If your team is small enough, you will find yourself directly responsible for output that either goes out to another team in the company, customers, or even worse - directly to the CEO. Most startups and small teams will operate a lean methodology which in this context means they will try to get maximum output with minimal resources.
To take ownership of a task or role is to be completely responsible (and accountable) for the outcome.
For example, say straight out of school you get hired as a Customer Success Specialist by “ moneyvest” a Nigerian startup that lets customers save money (I know). In a few months you’re responding to customers who make complaints via social media and to some degree you may become responsible for a range of tasks that include:
Assessing complaints and making judgment calls
Escalating to internal teams if necessary
Following up to ensure resolution while communicating with the customer at every step of the way.
In this scenario, you are responsible for the entire customer complaint cycle even though you write no lines of code and have no idea how payment actually works on a technical level. You have effectively become the Directly Responsible Individual for resolving customer complaints that come your way.
There are 4 elements of taking ownership that I would like to discuss namely: project managing yourself, communicating effectively, measuring what matters, and taking responsibility. However, before I get into it, it is important to note that some conditions should be satisfied before the elements I will share can be most effective.
Flat Management Structure: Do you report directly to a C Level Executive? Does your manager report directly to a C Level Executive? If yes, then you most likely work in a flat management structure, because the degree of separation (in the organizational hierarchy) between you and key decision-makers is little.
Small Team: For the purposes of this post, a small team is between 1 < x < 15 teammates with which you directly interact to achieve your desired productivity outcomes.
Open Communication: Basically you’re encouraged to email or send messages to anybody in the organization no matter how high up the management chain they sit.
Clear metrics for success: It is important that the criteria of success are very clearly defined to make sure you’re aligned with what is important at every time. This helps channel all your efforts most productively.
Autonomy: To some degree, you are left alone to choose how you work, what steps you take to achieve the outcomes (with some degree of direction from superiors of course), and can lay claim to the outcome on a personal level, even if you are not solely responsible.
Even if none of these conditions are met, these elements might still prove useful, I’m just highlighting them because they describe the conditions in which I have personally worked and thrived. Now let’s get into some of the key things I would say are important in taking ownership of your tasks.
————————————————
1. Project Manage yourself
This is a no-brainer, a person who cannot self-regulate cannot lead others or coral resources to achieve any desired outcomes. It is important that you make a plan or at least have a roadmap for what needs to be achieved, whether the piece of work is task or role-specific. Working in a small team sometimes means there’s a lot of ambiguity in what the final outcome should be, especially if you work in the very early days of a startup. The ability to tackle that ambiguity head-on and break them down into stepwise and manageable chunks of mini deliverables or subtasks is vital. A useful framework I use can be summarised below:
What are the expected outputs? It always helps to clarify what the outputs should be.
Determine the inputs which can range from a requirements list to resources like manpower, level of expertise of your teammates, technical ability required to more mundane things like electrical power and internet availability. I divide inputs required to achieve the output into 2 levels depending on what needs to be achieved:
Must Haves or Blockers: At a base level, these are inputs that are absolutely necessary on an existential level for the outcome to be realized. If you are pressed for time or resources and have to break your input into the absolute essentials, anything you put here makes the list.
Nice to Haves: Anything you put here adds a little bit of finesse to your output. They are not essential but are important to keep track of, in the event that you can squeeze out some time to input them. Ideally, they are a always lower priority.
Come up with minimum steps to achieve the goal. This should be discussed and validated with anybody involved in delivering that particular outcome. Once agreed, this should be communicated across board.
Draw out a schedule for achieving the goal. Personally, I find that dates are the most important method of imposing a schedule on any task. Sticking to them gives you a very objective metric for measuring your efforts and outcomes. Any deliverable that does not have a time estimate can theoretically go on forever, though in reality, this is not possible, you will undoubtedly fail to meet targets you do not set. Every task in a startup is time-sensitive and involves tradeoffs, so if you spend more time than necessary on deliverable A, deliverables B, C and D get delayed.
Execute, measure and track progress and be flexible because things will not always go as planned, but this assumption should have been baked into planning the schedule.
2. Communicate Effectively
Effective communication is one of the most important elements in achieving anything. Done well, it helps build trust between you and your teammates and most importantly makes sure that everybody is always working on the highest priority tasks. Initial planning, implementation, agreeing on deliverables, asking for updates, providing reviews, and agreeing on when a task or subtask is DONE is important. Open and honest communication is a basic requirement, this is because if you’re working in a small team, you will have to work with people from other departments to achieve a particular goal who also have mission-critical tasks to achieve that do not involve you, communicating with them helps you understand what their pain points are, helps them understand how they fit into your deliverable and helps you with making realistic time considerations. Lastly, for me, the most important reason to communicate effectively after you get the buy-in on what the inputs of the task are - is to get everybody involved in the task to agree on what “DONE” means. It can be really frustrating for members of the team if the goal keeps changing, it can be extremely demoralizing for them to return to a finished piece of work and frustrating for you since you are in charge of the deliverable and it will inevitably reflect on your competence. Failure to do this also has the potential to completely destroy trust in a team.
3. Measure what matters
It is a basic maxim of startup lore that what doesn’t get measured doesn’t get done or managed. I’ve seen this happen more times than not. Measuring progress towards the goal after designing the steps should be common sense but it is not always intuitive. The most important reason I can think of for measuring progress towards the goal is quality control - this is basically increasing the probability that the final product is what it is supposed to be. This is doubly important especially when the end goal still suffers from the shroud of ambiguity, I know this contradicts what I said about clear goals but the reality is often cruel. For me this comes in two steps, measuring the quality of the subtasks or sub deliverables and measuring the time progress towards the goal. Now for the first one, there are two broad ways to do this.
After every quantifiable step in your process, do some quality checks on the quality of the subtask delivered. Reviews should be baked into the process on a fundamental level.
If the process is a bit more automated, you can design checks at random points in the production process to check quality.
Personally, I recommend the first, but depending on the context there are definitely situations where the second is better. As for measuring time progress, this is important so you can quickly identify and remove any blockers and determine if the entire process is on schedule. It is always better to find out earlier rather than later because it allows you the flexibility to take swift corrective action.
4. Take responsibility
When you take ownership, you are responsible for the outcome - success or failure. It is important to implicitly acknowledge that. So learning to take responsibility for moving the task forward should be a basic requirement. An important facet of taking responsibility is learning how to say no to extra work deliverables - in order to keep the goal or outcome achievable and maintain a firm grasp on what “out of scope” means. Like I said earlier this will be easier in an environment where you have autonomy and where you are actually involved in setting the outcomes. Taking full responsibility also means that if you fail, you should not be shy to analyze your performance and ask for feedback from your teammates and superiors so you can iterate better on other tasks.
I hope I have at least helped you start an internal monologue on what it actually means to take ownership because I see a lot of people in the startup community mention it but never actually go into detail. Please do share and leave a comment if you have any questions or concerns.
“Any deliverable that does not have a time estimate can theoretically go on forever”
Thank you for pointing this out, it’s more important than people realize that giving estimated delivery timelines (however flexible) helps set the pace to getting tasks/projects done.
Really enjoyed reading this Akin A. Well done!
Thank you. This is really helpful as I am part of a number of small teams.