>On the other hand my ability to focus on a task has dropped considerably. I am no longer able to code for 1h straight. I would say that 15 minutes is a victory. This is a problem I will try to fix somehow during 2018.
My suggestion is: don't try to fix it. As an engineering manager with a team of more than 5 people, coding is no longer the most impactful thing you're doing. Making people and the team do better is far more leverage. As a fellow EM who also loves code, I've stopped coding at work. I find there are many, lot more impactful activities I can do: from hiring activities, onboarding & training, making oncall better, spending more time with my high & low performers and building bridges with fellow EMs, PMs, executives and other stakeholders and so on.
Also, you've not mentioned 1:1s. With a team of 12, 1:1s take a lot of my time (I do weekly 30mins - this is a lot, but has been essential to spot issues early and support people better)
Can't speak for the parent to your comment, but in my case my intent is to continue as a Manager and seek promotion to Senior Manager/Director as soon as it is feasible.
My policy is this: in this industry if the job description includes anything that hints at coding it's not a management job. It's an Individual Contributor role with some people-management thrown in, and one (coding) or the other (managing) is likely to suffer.
Or they come to HN to recruit individual contributors and not managers. You're wrong, though: every month I've looked there have been one or two posts including open EM positions.
That doesn't make sense because logically you'd be interviewed by even more senior managers than the position they're hiring for, and hence those people haven't coded in 10 years.
> coding is no longer the most impactful thing you're doing
This is pretty bad sentiment for an engineering manager. The reason you do coding is not because you want to contribute in overall output but because you want to understand nitty-gritty details of what your team is doing and where are the bottlenecks. For example, I as an engineering manager quickly learned that our build system was too slow and too fragile. Or that talking to one of the external system was huge struggle. Or that there was lot of code duplication in many places for certain functionality. Many junior and less experienced engineers would usually tend to just accept these pains and rather focus on their immediate deliverables. An experienced engineer would immediately see this as opportunity to sacrifice little bit of short term goal for huge long term gain. You can't build a city by only supervising things from 30,000 ft.
At absolute minimum, an engineering manager should do code reviews very frequently spending at least 20% of their time. My litmus test for an effective engineering manager is if they can debug and fix a trivial bug that any of their junior developers easily can. There are "engineering managers" who can't even build their own product that they claimed to have lead. Those are usually a disaster-in-works.
I'd agree if the team has no senior engineers, or in which the senior engineers are not adept at finding and communicating the issues you note, that the EM should fill in the gaps. I'd be skeptical of the long term viability of such a team. What you describe is more properly the purview of a Lead/Principal Engineer, in my opinion. The people in those roles should be able to communicate the technical issues to the EM, and the EM should have the technical chops to understand it (and the code). She shouldn't be hip-deep in builds and coding, and shouldn't need to be.
That's not to say no coding should be done by the EM, but it shouldn't be "impactful" in the same way an IC's coding activities should be.
I disagree and this is exactly the reason there is often so much dissatisfaction in the team with role of EM and consequently the rise of movement for "management-less organization". Why do you need bunch of MBA types just moving around from meetings to meetings and having no interest in how sausage is made while claiming to run the sausage factory. Delegating core technical responsibilities to some senior or principal is typical escape hatch adopted by such EMs. Such EMs are typically lacking monumental level of technical skills and delude themselves that somehow magical ill-defined "management" skills plugs those holes. The fact is that such EMs are not qualified to do pretty much any other duties such as hiring or firing except for making pretty Powerpoints to other higher up EMs who are exactly like them. In my opinion, non-technical management chains with views like above are precisely the reason why so many software companies are just B or C grade.
It's interesting you perceive that I am describing an MBA type and ignored the closing thought in my comment.
By the way, I was just last week promoted from Lead Engineer to EM. I am, as you say, qualified to hire, fire, design and code. I think you're too dismissive of key aspects of running a business. Coding isn't everything. It's not even the most important thing.
I mostly break-down leadership tasks into 4 groups
1. delegation
2. negotiation
3. vision
4. inspiration
A typical EM only needs to do two of those well, same with higher up the ladder, though not the same two through the ranks - in my experience, great ones hit all 4.
Delegation is mostly about tasks, negotiation is about interactions (either salaries with HR, deadlines with PMs or even figuring out what a specific employee wants out of a job, because not everyone responds to just money or prestige).
Vision is more complex - a manager needs to be able to guess the rate of funding for the current project, read the way the wind is blowing and navigate the team.
Inspiration is so rarely seen, because it is hard to connect the results to the actions (the "be positive" part of the blog) - but I've had engineering managers who've made me feel that I'm in a "safe space" to do interesting things, instead of the reality that I'm in a closely watched, judgemental situation with large sums of money attached to each action and reaction.
Management is not always equal to leadership. They can be very different roles. (And, they can of course overlap.)
One is more focused on tactics, the other on strategy. One is deciding which direction to sail, the other is making sure everyone is keeping the boat going in that direction.
"giving to other engineers features that I would like to do myself" is one that I struggle with as a data science tech lead. If I'm leading a team of people and deciding who does what, I want to give my team members the interesting work and not hog all the cool stuff myself, but I don't think it's a good use of my time to be doing only the tedious stuff. I'm not sure how to strike a balance there.
I would say you need to keep in mind that delivery of the team against product commitments should be a priority, and being able to do that in a long term sustainable way is very important. So in my view you should absolutely put out of your mind what you'd like to do and instead view it as what is the best way to complete the task at hand ( and making sure that can happen in a consistent reliable way). I'm a EM myself and there's no way that my day-to-day is consistent enough to code in a reliable manner especially when put up against other priorities that I have to deal with. What's more important?, you finishing a business critical feature you signed up for or helping a team member with crisis they are having dealing with another team member? (Or if you are more tech lead than people lead then compare it against more long term strategy planning and architect-ing you could be doing.)
If it's a particularly challenging feature or problem you might consider pair-programming as a solution. It allows you to apply your expertise (and scratch the itch of wanting to do things) while also letting another engineer contribute, learn, and/or demonstrate a different view.
The two things that a good engineering manager does well is handle the internal bureaucratic and process needs of the business and to improve the people those you manage. Often the best way to improve people is to teach them how to think about problems, and in the case of pair-programming they will be exposed to that teaching either intentionally or by osmosis.
I think that other engineer would be much happier if he got another task with little bit of autonomy and trust, instead of being forced to look how you scratch your itch while he nods along.
Teaching people because they need to learn something and acting like they need to be taught while in fact you just want to do something by yourself is not the same - and your underlings can tell the difference.
I believe that nowhere in my response did I suggest that you be incompetent in your management or be a lousy teacher.
I specifically mention that you look for particularly hard or challenging problems in which to do the pair programming precisely because it's an opportunity to both "scratch the itch" as well as teach. In every group I've ever worked in, worked with, or managed there were inexperienced people and those people tend to get less-interesting tasks simply because they lack the experience or knowledge required for hard, challenging, or critical problems. The best way to speed up their learning curve is to give them tasks that exceed their current capabilities, and the best way to minimize the risk is to provide the safety net of a more experienced and/or capable partner to help them learn to think through the problem and catch errors. As an added bonus it is entirely possible that the more experienced partner actually learns something from the pairing as well.
Give them hard task that you are not itching to do by yourself or don't have strong subjective opinions about. In any case, if your safety net is trully just safety net with enough autonomy for them, then supervising them won't satisfy your problem solving itch. Because it is not supposed to, good teaching is about allowing them as much independence as possible whole you limit yourself to keeping it safe. If you are intervening more then that, then you are not making them more confident about hard tasks (which is exactly what it sounds like you want to do as they tend to pick only easy tasks).
It is not true that all juniors avoid harder tasks, my experience was that they seek them. They are eager to prove themselves. Also, what is hard for them is not hard enough to challenge me.
You do not give them hard tasks that are critical because of the risk involved, until they prove they can be trusted with those tasks.
Supervising and teaching a junior dev working through a hard problem most assuredly satisfies problem-solving itches because in addition to having to think of solutions yourself (often internally) you also have to think about what they're doing and when they struggle you have to figure out a way to lead them to a better path and insure they understand both why they were struggling as well as why a particular path is better. Simply telling someone to do X isn't teaching.
I did not say that juniors avoid harder tasks, they almost always underestimate their limits and try and take on more than they are capable of. I said they tend to get the less interesting tasks, because no sane manager working in an actual business hands out the "re-architect our entire infrastructure" job to the most inexperienced member of a team.
Thankfully, critical and hard is not the same, so I can give them hard tasks that are low risk. And I can code review them and check on them while they are working.
There are interesting tasks for juniors, even easier to find that interesting tasks for seniors, they just don't tend to be large like "re-architecture everything" which should not be task for single person at all. And which is also largely political task (meaning it is as much if not more about negotiating and convincing people).
My experience with younger people is different than yours, clearly, but that might be influenced by how your and my company chooses people and how management behaves. My experience is really that they are very likely to underestimate difficulty and size of task.
The advice that most of them needed to hear were usually brainless easy to me - mostly concerning organization of work and code, when to ask customer, how to refactor safely, that sort of thing. Algorithmic or read-up-on-it technical or math or anything else requiring deeper thinking were things they were good at.
I think our experiences aren't that different but our view of what juniors need probably does diverge.
"Algorithmic or read-up-on-it technical or math" aren't the things I consider to be deeper thinking for programmers but instead are skills and methods that we'll always be continually having to add or hone. Deep thinking, which through my experience with others qualifies as hard due to the relative rarity in which I've seen them capable or willing to do, are much closer to the things you feel are brainlessly easy. That's not unusual since we often under-value the things that come easily to us by assuming that it comes easily to everyone. Learning how to _think_ about a problem, how to understand it at a fundamental abstract level and then build a mental and theoretical model needed to bring that vision to the point where implementation can occur is far harder than writing the code for the vast majority of people.
I also used to think "this is obvious and easy for me so it must be for others as well" but time and again that's proven not to be the case. I learned to focus on making sure my people can think the right way so that at worst they can respond to surprise difficulties or crises on their own but the best hope is that they become better than I am. With the right people in the right environment, if I'm doing my job well I will make myself redundant or superfluous.
Personally I think it goes better in this scenario when the manager/tech lead is not the one at the keyboard. That way the person who's learning can make a lot of the decisions while bouncing ideas off the other person. If it just becomes watch my manager do some work it's very hard to focus and learn.
But the whole original problem was that the manager really wish to do that task to scratch the itch. You can't simultaneously do the task the way you want it and simultaneously have someone else having do that. You will end up either annoyed that he does it differently or he will end up having to guess until he reaches solution you had in mind all along. It is profoundly demotivating.
Such task is just about worst possible choice for teaching task. Imo, if you want to do that task and have time for it, do it and don't apologize for that. As long as you don't cherry pick all cool tasks it should be fine.
And you if you think you need teach them something, pick up task best suited for whatever you want to teach. Not one you wish to do yourself, but the one that is best for learning.
Don't have personal hidden agendas around things like teaching and pair programming. Pair if you think pairing is helpful, not when you actually want to do it personally, but feel ashamed because your title is manager.
"Do the task the way you want it." That's a far more mechanistic view of "interesting work" and "features I would like to do myself" than the parent seemed to express.
> giving to other engineers features that I would like to do myself" [...] I want to give my team members the interesting work and not hog all the cool stuff myself ...
It even implies that they are fully capable and that he trusts them to do those tasks. It also implies that he indeed would like do that task, because he finds doing that task "cool".
Both are marks of good leader and so is being self-aware. None of them implies him team members need to be taught or that teaching instead of doing task them would satisfy his wish to do the cool thing.
Personally as a manager, I find doing the tedious work to be one of the best uses of my time. It helps keep my engineers happy and focused, which is the most important part of my job.
I would also hog all the tedious work as an engineering manager. I tried to make most of it go away but in order to allow people to grow in their careers, they have to be assigned "stretch" work.
Being a manager is an entirely different role than being an employee. Kind of like how someone could be a really awesome director of movies but may not be a good actor.
this is kind of unproductive. The job of the manager should be to push the envelope of the team as a whole. As such if he already has a high performing team, he should be as hands off as possible, focusing on other crucial areas. If not, his job is to create small proof-of-concepts of ideas and let the team take them forward.
This is a gross oversimplification, but why not just dole out the good projects round-robin, where you're just one of the members of the cycle? There's no reason why a manager should never be able to contribute work, just that they probably shouldn't always take the 'good stuff'.
Because as a lead, they may know a lot more about something, or have experience with it, or have thought about the specific problem space a lot more.
Sometimes it's that classic, "I can do it in 4 hours, but you will take 2 days. You do it, and learn something, and next time we'll be equals" kind of thing.
> On the other hand my ability to focus on a task has dropped considerably. I am no longer able to code for 1h straight. I would say that 15 minutes is a victory...
> When coding I try to be out of the critical path...
Sorry, you are no longer coding as an engineer on the team and are losing insight into how the codebase functions with a speed you are probably underestimating.
Engineering isn't about writing code that eventually works, it's about consistently delivering good-enough code on time.
> ... the company comes first, the team second and the individual third...
I think if you focus on building the team, there is no way the company and individuals do not benefit. Plus, high functioning teams often stick together across companies and employees follow managers. I'm not a manager just my 2cents.
I completely agree on your second point, obviously in the long run everything has to be for the company, but hands on the team is number 1. Particularly in larger organisations the only way to manage is to focus on your team and its sphere on influence because often there is no "best for the company". The best thing you can do is build a great productive team.
I completely agree and I think that if you take care of the people they will take care of each other (team). So when you've built a well oiled team that trusts each other the company benefits as well as they will be more productive and play well with each other.
Managing engineers is different from managing a manager (yes, they need to be managed too) : you don't approach your manager with a problem, you approach them with a choice in possible solutions. The trick is to make sure that whatever they choose, it's going to work out fine.
An engineer is different: you don't approach them with a task or a solution, but with a problem optionally with constraints.
This is definitely the biggest pitfall I’ve run into both as a managed engineer and as a manager. It’s intuitive to think delegation involves forming a specific task and giving it to someone else, but that’s a waste of their brain power. Giving them an open problem to solve is going to result in freeing up your mental energy and will make them happier due to increased agency. In general, you want to give workers as much agency as they can competently handle.
>As a manager, the company comes first, the team second and the individual third.
I think managers should take a little more nuance into this equation.
As a manager you sit between the interests of the business and the interests of your reports. Depending on the context the hierachy might actually be individual/team/company.
If you keep the model of company/team/individual, you will be seen as great at "managing up" (in this case also you might be seen as a "suck up"), decent at managing across departments, and your team will probably think you could care less about them.
There will be many times where this hierarchy changes and knowing when/how/why those changes happens will take you to next level management.
E.G. In a 1:1 with your report _they_ are a priority. (managing down)
In a company wide address on team performance, the needs of the company+the team need to be addressed. (managing up and across)
In an executive meeting, the needs of the company are paramount (managing up)
I do care deeply about the team and each individual, some of them are my friends. Ultimately, in order for all of us to have a job, the company needs to succeed. But I agree with the nuance. Thanks for the feedback.
While I hold the title of CTO for a funded startup I feel I have taken much more of an engineering manager role.
Ticket review, deployment, product development and general firefighting seem to be the order of the day; We have a team of 12 engineers, my biggest issue is being able to let go of the important tasks and be able to trust my team that they can deliver in the 9-5 schedule they enjoy (Entirely the opposite of the life of a founder).
Being able to hire someone to just take some of the devops tasks off of my plate is my immediate priority. I have certainly found that my skills are getting a little rusty as I'm no longer in the trenches cutting code each and every day, much more in a review / implementation position.
> Having awkward conversations, about missing a deadline, a particular behaviour, or some other thing, has created a psychological burden in me. In some cases it actually keeps me awake at night, thinking about some displeasing situation, which of course has ramifications in my overall performance later.
The best solution I've found for this is to start reading books related to managing teams, having difficult discussions, etc.
Once I did this, I found these kinds of discussions to be more of an intellectual exercise, opportunity for experimentation, etc. I.e., it gave me a level of personal detachment that made the discussions much easier, and hopefully more productive.
> A manager should be optimistic. A team's moral compass is highly influenced by their lead. I am skeptical and pessimistic by nature, I find it to be somewhat of a struggle to keep a positive outlook. In this particular point, I failed.
I find this challenging too. Any suggestions from other pessimists/skeptics for presenting a more positive outlook?
My partner struggles with pessimism, usually caused by focusing too much on the work ahead and too little on what has been accomplished. One technique we've found that helps is to keep a "done" list, separately from the "todo" list. The size of the todo list can be intimidating, but having a separate list which only records accomplishments that you can look over when you get stressed to remind you of just how much shit you've got done. From the perspective of a team, this could just be making sure that you spend enough time celebrating your wins.
I also find this challenging. One thing I can suggest that has helped me on my current project, is to do a morning standup. It's always brief but I use this time to set a mood/tone for the day. I try to lead with something relevant for the team or business, hopefully good news, but still try to motivate with a sense of direction towards what we're working on and where we're going. We'll each give our status and have an opportunity to bring up blocking issues, successes, or anything else. But I've found that my team looks for this ritual to assess my mood. I try to stay optimistic towards the effort, our business and the opportunities we're all working towards. When it gets slightly frustrating on a day to day basis where the "business" side may not be meeting the "engineering" side, I try to make dry light humor where we can laugh a bit during standup knowing that we're pointed in the same direction. Not an exact science, but on the day to day, try to find something to laugh about. This usually finds people willing to pair up together to take on "the cause" or whatever the team needs to get done.
I find that pessimists miss a critical factor a lot of times.
Things that are empirically bad are just going to suck.
Things that are just "hard" are going to suck too.
In business RARELY are things actually bad (site outage, layoff) and often just "hard" (I need you to work late).
When things are hard you can say they are HARD and let them be HARD and use the occasion as a chance to create camaraderie. Stuck late in the office, then start singing show tunes badly - bring in food and beer (if appropriate) or good coffee the day after - hard times build great teams if they aren't "every day"
Find a things to have with your team to make it more entertaining - I worked in an office that ran on the back of quoting film, and there is a film quote for EVERY situation. A good friend of mine works in a "nerf gun" office, and I used to work in a place where "team lunch" was a thing that was sacred (you would leave every day for an hour). Alone these things don't do much but when it is HARD (or bad) the activity restores a sense of normalcy for you and your staff.
Be honest about hard, sometimes you just need to STFU about bad (layoff).
I find that pessimists miss a critical factor a lot of times.
Optimists miss critical factors all the time also. Which leads to all sorts of problems with expectations.
I think the real answer is to be optimistic about people, but realistic about projects.
You are right about hard vs. bad, but it's also worth noting you have to be careful about pushing your own ideas of team support. When you are asking more of people (stay late) it's worth thinking about what you can give them that they want, not what you envision. And if it gets really HARD, think about how hard you can advocate for getting them something material after (promotion for performance reasons, extra time off, a situational bonus, whatever)
I too like to dwell on the negative side. When you're the boss everyone really is looking to you so it is important to keep everyone's morale up.
Hopefully by the time you're a manager you realize the grass isn't perfectly green anywhere, and every team has good and bad points - remind everyone of the good that is happening. Maybe you have to start policies that people will like ie interesting tech or tools. Even if things are going badly you can have team lunches or drinks that are non-work related - it really helps team spirit.
I find that the biggest intellectual mistake of pessimists is that they take an actuarial view of reality: "99% of startups fail, thus we are doomed from the get-go and our <current problems> are evidence of that".
This might be correct if you take a 3rd-person perspective view, but ignores human agency and the ability to steer situations - sometimes via sheer willpower.
See Paul Graham's essay on Intellect vs. Determination.
I disagree that something a manager should be chastening developers for at a product company is missing a deadline.
When your only stakeholder is the user, deadlines are all artificial. It might be different at a consulting company.
I'm not saying companies shouldn't estimate and schedule work, but missing estimates is almost never an individual developer's fault, it's systemic and/or a failure in management.
If a developer isn't productive enough for their seniority level overall... that's something a manager has to address. But if a developer misses a deadline, it's probably the manager's fault. It's probably the manager who needs to be working on their estimation and tasking methods.
When I was doing management in software companies, I found Management By Wandering Around (MBWA) [1] to be useful.
Being an unstructured activity (but still planned, in the sense that you knew that you were going to do it now and then during the day or week), you tended to get more out of it in terms of information about progress, status, issues, and being able to help team members, technically or otherwise.
It was supposed to have originated, or at least been used early on, at Hewlett-Packard (and also earlier by Abraham Lincoln :) see [1]).
Although I worked for a while in a company that was a joint venture with HP, I did not learn about MBWA there, but later on, in another company where I was doing management. Read about it in a management book, thought it was a good idea, and tried it out; turned out that it was useful.
Not to detract from your experience, but this sounds a lot like micro-management.
You should not have to check up on the status of ongoing projects; you assigned those projects to someone with clear deadlines, etc. etc. If you don't trust that person to be able to finish it: why did you assign it to him? If you do trust that person to be able to do what you asked: why are you bothering him about the status of the project?
Thanks for your comment, I am open to discussion or disagreement, although I may or not agree with the specific points raised - on a case to case basis.
>Not to detract from your experience, but this sounds a lot like micro-management.
In this case, I disagree that it is micro-management, although I do think that if overdone, it can degenerate into that. It is a matter of degree and also of how it is done.
See my replies and quotes of excerpts of your comment below.
>in the sense that you knew that you were going to do it now and then during the day or week).
So the emphasis is on "now and then" (and "now and then during the day or week" did not mean "multiple times during the day with the same person", at least as I used to do it).
Once a day with a few people (not every member of the team per day, e.g. in the case I am talking about, I had a team of 10, and might have had the one-on-ones with say one to three of them per day, and not every day either), and that would be enough, unless there were some serious issues, in which case more management or help or guidance is definitely needed, or the manager is not doing his/her job.
Also, it was not like I was grilling them on goals and deliverables each time I talked to them - it was more like sitting down next to them and asking "how is it going?" and only if they mentioned any issue or problem, would I delve into it and see if I could help. Sometimes they would themselves tell me that they had an issue and ask for advice/help. It was not an antagonistic relationship. In fact the chief accountant of the company, who sat in a section next to us (this was a company with cubicles, ha ha) once said to me (presumably he could overhear us talk since he sat near us) that "you have a good team". I took that as a compliment.
Actually I also used to informally (as in, not a formal code review, although we had those too) look at the code they were working on currently, and sometimes would spot issues (could be small ones like redundant computations like checking the length of a string being looped over, in the for loop itself, instead of before it (aka code hoisting - see Writing Efficient Programs by Jon Bentley).
It was technical and project management, BTW, not MBA-type management. (Project management might have a different connotation in Indian companies from some Western ones, in case you don't know that. In Indian companies it tends to be a blend of both technical and project management (as US people understand the latter term). (I've worked in/with both Indian and US startups and large companies (all 4 combos), that is how I know this.)
Also, in this particular team, they were all freshers, just out of company training after being recruited, so more management was needed. [1] But I think MBWA can be helpful even with more experienced people who report to you - maybe at a lesser frequency.
Multiple issues with your comments below:
>You should not have to check up on the status of ongoing projects;
Sorry, wrong, IMO. A manager's job is to manage (though not micro-manage; hell, even micro-management may be appropriate in certain situations, depending on the skill and experience level of the managed people, and a host of other factors.
Please don't generalize. And checking on status is a normal part of management duties.
Repeating:
>>You should not have to check up on the status of ongoing projects;
That is so far off the mark that I am almost at a loss for words (but not quite :) If an employee cannot handle the fact that the status of their work has to be checked on, then they are violating the contract that they voluntarily signed up for when they joined the company (except for free-wheeling companies where they may be no such agreement), because in most employment agreements, it is a standard clause that the employee has to follow the instructions of their managers (obviously, only regarding work, not anything else, and within reasonable limits, but status reporting and checking is very much a part of reasonable limits).
As I've heard it said, a project or a company is not a democracy. Just check out real democracies if you want to get an idea of what chaos can happen if you run a project or a company as such, ha ha. That does not mean that it has to be a command-and-control situation and everything is to be decided top-down either - that often does not work too. It just means that there can be a reasonable amount of discussion about how to do things, what to do, etc., between the team members and the manager, but ultimately the manager's decision has to be final (mostly - and any enlightened manager who does not have ego issues should/will accept the suggestions of team members if they are better than what he/she thought of). Of course there can be incompetent or evil managers, for that the remedy is to go report the issues to higher levels or other options (including legal), as needed and makes sense.
And:
>>You should not have to check up
The manager carries the responsibility for the results of his subordinates, so he definitely can and needs to check up. I am not sure, but based on your comments, you might be coming from the background of some small US startups, where everything is on the fly, free-wheeling, "cowboy coder"-style, etc, or might not even have worked much in real companies. I don't mean to denigrate that approach in total, but in many cases, it does not work. I have been on both sides of the fence, for non-trivial periods of time, both working for/with small and large (so-called "enterprise") traditional companies, as well as small free-wheeling US- and Indian-based startups, at different times in my career, including switching from one type to the other and then back again, so have seen both (or rather multiple) sides of the picture, and have come to realize that there are pros and cons to all those approaches.
In fact I have even worked in traditional (aka non-startup companies) of both the free-wheeling / "cowboy" as well as the more formal / process-driven kind.
>you assigned those projects to someone with clear deadlines, etc. etc.
Who said the deadlines were clear? Were you involved in that particular project, so that you know?
>If you don't trust that person to be able to finish it: why did you assign it to him?
Even this statement shows you talking about stuff you do not know about. Who told you that I assigned it to him? Can it not be the case that I was given a team to work on for the project, and had no say in the choice of people? Does that seem impossible to you? Do you always get to select your team members, if you are or have been a manager? (Then you might not be much aware of business realities, which are not always (or even mostly) aligned with what people involved would like things to be like.) That was the case here, in fact - I did not get to choose the team. Stop making so many unfounded assumptions.
>If you do trust that person to be able to do what you asked: why are you bothering him about the status of the project?
See reply to above point (too). Sorry, I'll have to call that a very idealistic and impractical notion. In business, to quote a saying: It's not the things that are expected that get done, but the things that are inspected.
[1] There is more that I can say, including some shockers, but this comment is getting long, so I will just give a hint or two:
The company used software engineering practices (it was not a startup, BTW), and required software engineers to use checklists for different phases of the s/w dev life cycle.
I have seen (example of shockers) team members do things like dutifully place a printed copy of the checklist for, say, program spec creation or unit testing, on the desk at the side of their PC, and then proceed to happily ignore it while doing the actual work!
Another and worse example: a dev on my team (actually saw this on his screen) wrote an if statement to check for an error after some operation, and then happily printed a message that there was an error, and went on to write the code for a following operation (after the if statement and error message printing) that depended on there being no error. IOW, print the error message, but then go on as if no error happened!
I rated him the lowest of the team during appraisals, because that error of his was avoidable by sheer common sense; you do not even need to understand anything about programming to avoid it. I mean, it's like saying: I see a deep ditch in front of me, I yell out a warning about it, then proceed to fall into it!
Of course this was an outlier, but you may be surprised about how often such kinds of blunders can happen, even at somewhat higher levels in companies.
Or even without ADD, you might wish to look for a correlation between your attention span vs. how well you slept the night before.
Getting a good night of sleep seems to get more difficult as we get older. Lack of sleep impacts many aspects of mental performance, including attention span IME.
The direction is most important, everything else is secondary. I can develop better code if I know what is coming in following months. I can optimize where it is needed or hack quick solution when I know technical debt cost.
Being a team cheerleader is nice but leading in the right direction is critical. And yes, you need to be technically sharp if you want to make any assessments on individual performance. Code reviews, architecture design, post-mortem and sprint reviews should be EM main thing.
My suggestion is: don't try to fix it. As an engineering manager with a team of more than 5 people, coding is no longer the most impactful thing you're doing. Making people and the team do better is far more leverage. As a fellow EM who also loves code, I've stopped coding at work. I find there are many, lot more impactful activities I can do: from hiring activities, onboarding & training, making oncall better, spending more time with my high & low performers and building bridges with fellow EMs, PMs, executives and other stakeholders and so on.
Also, you've not mentioned 1:1s. With a team of 12, 1:1s take a lot of my time (I do weekly 30mins - this is a lot, but has been essential to spot issues early and support people better)
Good luck for 2018!