I have been a solo dev / indie hacker for a few (many?) years until recently when I added 2 people to my team (one engineer and one for marketing). Initially when adding them to my team I was kind of relieved that they would solve certain problems for me however after a few weeks I learnt while they do what I ask of them they also create new problems for me and I need to prepare a lot more which leaves less time to work solo. My impulsive thought at first was that maybe I should go back to being solo but soon I realised that I enjoy working solo and don’t really know how to be a manager or how to delegate.
Has anyone here faced something similar? How did you learn to become a manager?
I would really appreciate if you could point me to some good sources books videos courses any material that could give me a good 101 on being a manager and delegating work / using Human Resources, also using positive approach whilst giving feedback. Also, do you have any heuristics you use to measure your effectiveness at delegating?
Any help is appreciated, thanks!
Info about him is at https://en.wikipedia.org/wiki/Ricardo_Semler
Right now I'm going through 37 Signals books just for the fun of learning..."Getting Real" (2006), "Rework" (2010), "Remote" (2013), "It Doesn't Have To Be Crazy At Work" (2018), "Shape Up" (2019). Might be something in there.
(I'm now retired, but still trying to figure out what the right way of living and working should have been. Luckily, I'm financially OK despite a lifetime of bumping into walls and dealing with shitheads at exactly every job I've ever had. At least I knew how to live frugally and save money, so I'm free now.)
As far as specific task delegation, if you are looking at your task list, I'd recommend a modification of "Eisenhower Matrix", that looks like this:
- Important / One-time Tasks - Keep for yourself.
- Important / Frequently Repeating Tasks - Delegate with high priority.
- Not important / Frequent tasks - Delegate with low priority.
- Not important / One time tasks - Delete.
A quicker way - buy their Effective Manager book today, read it over the weekend.
Here is one approach. Not perfect, and there are obviously going to be cases where it doesn’t apply. All models are wrong, some are useful.
A good metric for delegation in your case is “How much work am I doing that could plausibly be done by someone else?” Let’s call that value X, and the ideal value is zero.
Ex: you are the only one who can make strategic decisions for your company. You are not the only one who can send a promotional email.
Your process as a manager should be to systematically lower X over time. Reasons X is nonzero include but are not limited to:
- New staff need training to learn how the org etc works. This should be temporary but unavoidable, and explains why you feel like they are making more work for you.
- Staff need to upskill to take more off your plate. This means either you pay for training or train them yourself. Short term loss for long term gain.
- You have not hired the right kind of staff for the workload you face. Maybe you hired an engineer, but on balance you should have hired an accountant since that actually takes up more of your time.
- There is more work than can be handled by staff. This is an urgent problem that you need to resolve. If you burnout staff you end-up in a death spiral of turnover. The solution might be to replace inefficient processes/systems/practices, reduce work through trimming features/customers/whatever, or hire to handle growth.
Delegation: be sure that the person you're delegating to can actually handle the task, wants to handle the task, and that you are really OK with them taking on the task. Don't "delegate and hover." Delegate and leave them alone until whatever time you've asked for feedback on how it's going.
In general think of being an manager as always being concerned with how you can best make your team successful. The comment from /u/ws66 that "you now work for them" is very insightful.
- Out of the crisis and The new economics, Deming
- Workplace Management and Toyota Production System, Ohno
- Peopleware, DeMarco & Lister
- Managing the professional service firm, Meister (delegation)
- Leadership Handbook, US Army
The book that has made the most difference to me as a manager is Crucial Accountability and it's very relevant to what you're asking about.
I'd really encourage you to do an intro to line management type course as well. I've never known anyone come out of one saying that was amazing but people always find them useful.
Getting a proper answer depends on location. Employment laws vary a lot for any feedback to be relevant.
You really need to understand the concept of leading from behind and empower the people working for you, so that they'll be motivated to do a good job and have enough "jurisdiction" to think with their brain and optimise the work. You don't want to work with automata you need to constantly micromanage.
Give them bigger chunks of work - the things you need to solve - they need to be in charge of that, as a team.
Ultimately you could give a very generic objective and let them come up with a solution. That sounds like a dream job to me.
Of course in order for this to work, you need to trust your collaborators (or fire them and replace them with people you can trust).
Remember Pinker's Autonomy (give autonomy), Mastery (let them get better at their craft) and Purpose (make them understand the mission).
Good luck, it's a bumpy road.
If you’re a typical line manager and just got handed a team with no say in its composition, well, good luck. Nevertheless the best you can do is fit together the pieces you have as well as possible.
Most people don't know what to manage means because most of what's written on it is about the How(s), and not the What or the Why of it. When it clicks that to manage means to extract value from, a lot of how to do that falls into place. The value from people can be in terms of work, tasks completed, commitments to outcomes, growth of a persons skills and the quality and efficiency of their work, etc. Lots of possibilities. Whereas managing things usually means assets and money, and it's analogous, but not related to the OPs question.
Often people use the word "managing" as a black box to mean they'll make decisions about it, usually later or when they have to, but that's not really extracting value from something. Being a gatekeeper or critic isn't managing either. Your job is to be a proxy for the desire for the value your team generates, and the better you understand (and in turn, appreciate) the value it provides, the better manager you're going to be. When you get a lot of value out of people, they feel valued, and it's a positive cycle. If you don't get a lot of value out of them, you treat them like shit and they notice that as well.
A manager of people understands the value their team provides outward, and finds ways of getting that value out of the members using various tools like mentoring, examples, incentives, clear vision and alignment, service and esteem maintainance, acknowledgment and appreciation, among others. Once you have this frame of mind about extracting value, you have most of what you need to manage well.
* Creating the right environment for teams to do their best (See book Leading Teams below).
* Being skillful at challenging pre-conceptions.
* Coaching people and teams to work in the most effective way.
* Communicate, communicate, communicate.
* Hiring people who are smarter than you.
* And, a difficult one, having honest 1-to-1 with people when they are not delivering to know what is going on in their lives and, in the worst case, to help them go (aka fire/made redundant).
My favourites resources are:
* Turn the Ship Around by David Marquet
* The Five Dysfunctions of a Team by Patrick Lencioni
* Leading Teams by Richard Hackman
* The Goal by Eliyahu Goldratt
I'm not a manager (I don't like managing people), but I've been working for ~13 years coaching engineer managers, tech leads and engineers. You have to let the baby go so the people you hired (which should be smarter than you!) can do their job. Obviously if you see something that is wrong, by all means raise it, but be careful that it's not a matter of taste as this will alienate them.
I read it several years into my management path and cringed when reading a few of the anecdotes realising I'd made the same mistakes.
The Rands' Leadership Slack is also a wealth of knowledge and advice.
The cargo-cult mimicry approach -- Just telling people to do something, then supporting them as they muddle through it -- can get you surprisingly far. "Support" includes pairing with them / being available for support / writing documentation if something's consistently unclear / good reviews / etc., basically resolving the delta between what they have and what you want.
Also assigning and designing work that balances pedological value and blast raduis, which is case by case. E.g. junior Dev gets the design of a new system which is isolated, loosely coupled, and has no tight deadline; senior gets to debug a critical outage; senior gets a time critical important new system with many integrations; junior gets adding a new SQL backed api endpoint that looks like the others, etc.
Soon enough your minions will have a better understanding than you, and you will then have the opposite problem of feeling incompetent and wondering how to regain your comprehensive understanding of what's going on.
[1] https://internalmedicinefaculty.wustl.edu/wp-content/uploads...
Another that I haven't read but has been recommended to me is The Manager's Path.
This article is also good: https://charity.wtf/2019/01/04/engineering-management-the-pe...
I recommend Managing Humans and Bringing up the Boss. They are the most practical and useful day to day. Avoid Making of a Manager. It’s recommended often but it’s a memoir masquerading as a management book and way too focused on the writers specific situation.
Also get coffee with your HRBP. They are a wealth of knowledge and best to start the relationship before you really need them.
They will do it differently than you. Accept that. As long as the goal is accomplished it doesn't matter how they got there.
As long as they understand why they are doing something and the constraints, magic will happen. In the meantime get out of the way and clear blockers for them.
That aside... Trust. Trust your team, trust your manager, trust other teams. Resolve or escalate when that trust is violated (which ideally is a 1:1 conversation as a first step). Just try to remember that most people are some degree of competent and are trying to do the right thing.
Managing is an incredible opportunity to spread your knowledge around and increase everyone's productivity (and hopefully happiness). Your job is to unblock your team through any and all obstacles. Hopefully your experience helps here, and to increase it you should try to get another manager to mentor you.
I've been managing for a few years now. I miss the coding sometimes but I like watching people grow and being part of that growth.
Directing / Coaching / Supporting / Delegating
I've found these to be good ways to frame tasks (even if only in my own mind) when assigning to others. It forces you to acknowledge how much support you expect the person to need, which you can then match to what really happens, and then adjust. The quadrant that applies will change by person and task.
[0] https://johnkwhitehead.ca/situational-leadership
[1] https://johnkwhitehead.ca/wp-content/uploads/2016/09/situati...
A "task" is often hard for software engineers to grasp because they think in terms of units of coding activity, like handling a ticket in a Sprint queue, but a task in a business sense is generally a larger activity than that.
For example, think of a work project. One of your responsibilities as a manager is likely to break that project down into smaller pieces. If you keep breaking these pieces down, the atomic-sized piece is a "task", which should map more or less onto the work (some sequence of actions) a single person can accomplish in a short period of easily projected time.
However, tasks also come with a kind of protocol, you must define the task, the expected projected delivery time, the success criteria, and then know how to integrate the delivered work back into the larger project.
Very important, you have to try to carve the task out so that it can be accomplished by your staff given their capabilities, and if there are elements of that task that are outside of those capabilities marshal resources from elsewhere to fill in the gaps.
Here's a semi-technical notional example:
Project: Integrate with upgraded vendor supplied data source.
You might break this down into tasks one of which might be some database work to be accomplished by your Database person "Jane". The task might be "prepare database to receive upgraded data source".
Jane receives this task, thinks about the sequence of actions she has to do to accomplish this task, then goes about doing them. Perhaps she's unclear about one of the tasking requirements, and decides instead of dropping the old table, or renaming it, she'll put the new data into a table called "new_vendor_data".
Jane finishes the task in a day or two, and lets you know she's done and that the new data can go into the "new_vendor_data" table.
Your job is then to integrate this information into the project, which in this case might mean you go to "Peter", who's working on the ETL from the vendor's API and let him know now where to put the data, then you go and update the database and API documentation, and think through any other places where this information is needed.
The lifecycle of the task is now complete.
This is a really trivial example, but the method for how it works translates into non-technical fields. You can build tasks with your marketing staff member and see them through their lifecycle as well -- defining success criteria, and such unique to each discipline.
At larger scales, defining these tasks, and coordinating their lifecycles becomes a pipelined and multi-threaded discipline, and being good at it is part of what makes one a good manager and an efficient and effective team. Very good managers view this as a service they provide their staff that keeps them running with full work pipelines and no downtime or uncertainty.
There's some simple stuff that seems worth pointing out:
1. You need to do it more often. Education 10%, Exposure 20% and Experience 70% as a rule of thumb for learning.
If you want to be better at managing, then practice managing more. You're not losing time for solo dev work, you are gaining a new skill.
2. Get a close mentor you can shadow for that 20% exposure time.
3. For delegation, practice using CPORT.C – Context. P – Purpose. O – Outcome in terms of quality and quantity. R – Resources. Then get fast at it by creating systems that do it for you. Queues are your friend.
Have fun.
The number of times you see people promoted to a “manager” with the expectation that they will do that and continue at the same level of IC output is ridiculous.
Management can be and often is full time job.
In your situation you will need to spend more time mentoring and coaching your staff until they learn how you want them to perform.
Give them problems along with the constraints and how success will be measured. Then monitor progress and correct as needed.
This will mean that you have less time to do the work you were originally doing.
I think if you are in charge of people then that is you main job. Coding fits in around it. Some weeks you won’t code.
For real though, there's stuff that needs to get done, it's your job to tell the guy to do the job. Ez
The biggest thing you need to do is change your mindset. It doesn't matter what you get done, it matters what your team gets done.
This doesn't need to be all that hard. Give a person a problem that needs taking care of, make sure they have whatever they need to get shit done, and let them go do it.
Two other notes, just because I strongly suspect you're going to run into them:
1. Onboarding is hard work. It takes time. You're not going to be able to delegate everything on day one. Start with one thing, then add another, then the next. In some cases, the only way to ensure someone has enough context it take the problem over is to pair on it for a while. This is time consuming, but its an investment.
2. Being a solo dev for a long time, you might have strong opinions about the right way to do things. Your team isn't going to want to do everything your way and can't read your mind. This is a good thing, the team's collective brain just got bigger. Embrace it.
I've also found just being human goes a shockingly long way. If you're honest, share information, and treat people with respect, it turns out they'll like working for you. This really shouldn't be a surprise, but the bar is quite low.
