
Things I was unprepared for as a lead developer - nkurz
http://dev-human.com/entries/2015/09/07/things-i-was-unprepared-for/
======
unoti
Probably the biggest surprise I've seen in my career as a team lead is how
often people ostensibly work with the team, but actually want to see the team
fail. It sounds ridiculous, I know, but it actually happens quite often.

Here are two quick examples where I see this happen often. Let's say you're a
vendor deploying software at an organization, and one or more people that work
at your client organization originally wanted to write their own solution for
this software, and their bosses overrode their wishes, and now they're forced
to help implement your software. You need to use those disenfranchised IT
people as part of your team to do the implementation, but they'd like to see
the project fail, because they told their manager they could do it better
themselves. Other variations of this occur whenever someone doesn't get their
way, and is forced to go implement things a different way -- now any delays
that happen may demonstrate their sage wisdom in not wanting to do it this
way.

I've also seen variations on this same theme where a company is working on a
product that does what we're implementing, but it's not ready yet. Then a year
down the road, when we're doing the final rollout, their product is almost
ready, so now they'd like to see us fail. And suddenly the alliance falls
apart. Over the last 30 years working in IT, I've seen something like 20-30
variations on this theme.

Lots of times you need to work with people who really want to see your project
fail. This came as a huge surprise to me, but I think any senior person should
be careful and on the lookout. It's often a significant project risk, and
almost always overlooked.

~~~
stevoski
I've definitely been that person who didn't want the project to succeed - and
I was the key developer (and an external consultant). I was convinced that we
were implementing the wrong thing. Even though I tried to suck it up and do
the job, it was hard to do my best on something I was sure was going to fail.

I had to be talked out of quitting a couple of times. I think they might have
been better letting me quit the first time, and getting a replacement who
didn't have so much ego affecting their work.

~~~
troels
That's a very brave and honest comment!

~~~
ak39
Yes it was. But would it not have been braver of him to support the project by
putting ego aside?

~~~
andrewingram
In fairness, he did say he _tried_. Perhaps there was a lack of bravery,
perhaps he could have gone to this bosses and explained the situation, but
perhaps he did that and it wasn't enough.

~~~
aknosis
It's also likely that he didn't realize what he was doing at the time. Maybe
he felt upset or stressed about the situation but not necessarily that he was
subconsciously hoping to failure.

------
dmitrygr
> does wildly inappropriate acts such as coming in late and/or leaving very
> early

Man, am I glad I do not work on your team. If you judge coming in late or
going early as inappropriate, as opposed to measuring actual results, then you
have failed as a leader already. Sorry.

~~~
timv
I disagree. I think at least part of that is cultural (I'm in Australia), and
part is about what "measuring actual results" really means.

The idea that you _only_ measure results is a worse situation for the
engineering team than measuring time.

If we only measure results, then a piece of work can be estimated to be "a
week's work", and then the engineer is expected to deliver on that estimate
and have it done by the end of the week, even if that means working overtime.

I don't want that. I want to be able to tell my team that, if they did a solid
week's work on it, and it's not done then that means our estimates were out
and we'll adjust the plan. But _that_ is measuring time - they did a week's
effort even though they didn't get the intended result.

The flip-side is that if something is estimated to be "a week's work" and they
get it done in 3 days, then I don't expect them to take the next 2 days off.
Rather, it means that our estimates were off (in the opposite direction) and
we'll pick up some additional work this week.

To me, "taking 2 days off" and "only working 5 hour days" are essentially the
same thing. So if I had a team member who told me "the task I was assigned for
this week is actually pretty easy, so I decided to just finish at 2pm each
day", then I'd consider that wildly inappropriate and tell them so.

In the same way, if a manager told an engineer "the task you were assigned
this week is really hard, so you're probably going to need to work until 9pm
each day" that would be wildly inappropriate.

I don't care very much _what hours_ my team work, as long as it's effective -
which includes having enough overlapping office time do have in depth
technical discussions, and so they can provide mentoring and advice to junior
team members (or get advice if they are the junior). But if someone is "coming
late _and_ going early" (direct quote from the article, but the emphasis is
mine) then they're not doing the job that they're hired for, and we need to
discuss _why_.

Most engineers aren't employed (paid) based _solely_ on results - and don't
want to be, they want to know that if they do their hours, then they've done
the job. But conversely, if they haven't done their hours, then they _haven
't_ done their job.

~~~
facepalm
But the job is presumably not "being there from 9 to 5", it is to implement X.
So why are you saying "they are not doing the job they are hired for"?

~~~
falcolas
I've yet to work at a job where my job was solely to "implement X". It is
usually more along the lines of "apply 40 hours a week towards corporate
goals."

My team has a feature and bug backlog half a mile long; I could clone myself
and still not run out of work. And even if I did manage to close out the
backlog, there's more work which could be done towards company goals.

------
vellum
> They looked up to me for leadership and that also meant defining what was
> and what was not allowed. Of course, this is easy when somebody makes a
> remark that couldn’t pass or does wildly inappropriate acts such as coming
> in late and/or leaving very early. The hard part was when this coming late
> and going early was done for a good reason, such as a sick spouse or child.

How is this the hard part? They have a valid excuse. If they work remotely or
get their work done, it's not a problem.

~~~
dangero
This is a tangent but, as a father I've always felt the sick child/spouse
excuses were dumb in the same way that smokers were allowed to take extra 15
minute breaks at one of my jobs. Shouldn't the presence or absence of a family
be irrelevant to your employment rules?

~~~
shanemhansen
Life doesn't actually stop when you clock in. I think it's reasonable from a
business perspective to realize your resources don't work 100% for you 100% of
the time.

However, if the company really want to disallow people missing time here and
there to deal with family, I really hope they'd never ever ever consider
asking them to work before 9, after 5, or on the weekends no matter how high
priority the business tasks are. I hope they're the kind of employer that
turns off email at 5.

For me, the time I take to deal with my personal responsibilities at work is
more than balanced by the time I take to help my employers out outside the
hours of 9 to 5.

~~~
sokoloff
> I think it's reasonable from a business perspective to realize your
> resources don't work 100% for you 100% of the time.

I also recommend barring the use of the word "resource" when you specifically
mean "person". Capex, opex, machines, buildings, presses, are all resources.
Allowing your leaders to talk about people as being "resources" biases them to
think in a certain way (or at least risks that).

It is unfortunate that in the phrase "human resources", "human" is an
adjective... ;)

~~~
perfTerm
Hmm, I don't really think its off by much, especially in Westernized nations
where practically every thing is governed by contracts, regulations and
legalese. And especially at a management level. You allocate resources to
accomplish tasks. If you have a C++ developer, that's a resource. Resource X
costs Y and produces Z could be applied to JetBrains licenses or people.
Maintence for licenses is quite simple requiring updated payment information,
maintence for people is a lot less clear cut and requires communication, and
lots of ambiguous judgement calls. It's stale but I'm not sure there's a
better word to fit in its place.

~~~
sokoloff
Denotation of people on salary as a "resource" is correct, and I'm even OK
with including people in a collective set of varied types of resources. "We
just don't have the resources to pursue all possible ideas" and the like is
fine.

I'm recommending a terminology change to always call people "people" as it
biases your leaders to think of them as special and different from licenses,
machines, money, and black boxes. (It's not my idea originally, but I've seen
it play out at my company and believe it to be helpful.)

------
abalone
This sounds like an engineering manager role, especially since it involves
hiring/firing and setting salaries.

Why is it called "lead developer"? The cynic in me thinks it's to make it more
palatable to promote engineers who still want to code. But as this post
details, that's the wrong expectation.

~~~
developer1
OP sounds like he works for a startup, where he's given the title of a Lead
Developer, but is expected to perform the role of an Engineering Manager and
even some CTO duties. In addition to hiring/salaries, also worrying about
software licenses? This is not the description of a lead developer.

~~~
MrGando
I totally agree. Lead developers write code, also remove real, tangible and
hard roadblocks in the code for the team... this sounds like a bureaucratic
nightmare. I think he was turned into a manager without him realizing it.

------
codingdave
That really sounds less like a lead dev role, and more of an actual management
role.

~~~
krallja
Yeah, I would categorize this role pretty firmly as an Engineering Manager.

~~~
kijin
In a small startup, it is not uncommon for both roles to be performed by the
same person.

------
vblord
Some of the things listed in this article are more of a manager's role instead
of a lead developer's role. With that being said, every company defines the
lead developer role a bit differently.

For anyone that is interested in a lead developer role, you need to understand
that there will be less coding. The amount of less coding is dependent on the
company. Some companies expect 60% coding out of you and some companies expect
a maximum of 10% coding out of you. If part of your tasks include delegating
work to your coworkers… be prepared to give up the fun stuff. I often find
myself doing the boring stuff so that the people that work for me can enjoy
what they do. I personally enjoy the team lead role, but if you are interested
in moving in to a team lead role, you should really understand what the
company’s expectations are… because every company has different expectations
for that role.

~~~
bliti
Lead here: My own experience with various companies has been that they expect
100% with the additional management work on top (like a cherry). You end up
delegating a lot of things and get tired quickly. I'm currently working on re
adjusting this issue and it's going much better. Still is a lot of work with
little benefit. Except for the ability to help others grow into better devs. I
love that part.

------
trustfundbaby
> Way less developing

I've worked in an organization where leads were expected to do all that a lead
is generally supposed to do AND also have sprint velocity (work throughput)
equal to or higher than _senior_ engineers on the team. I always thought this
was absolutely bonkers, but at least now I know I'm not crazy

------
draw_down
I have been told by people that I'm a "natural leader", perhaps not to the
extent of the author. But I am just uninterested in all this stuff, I'd have
to be paid double or something.

~~~
developer1
I'm in the same boat. I've had management at a handful of companies discuss me
taking on more than my Senior Developer role, for an extra $10-20k. That much
stress does not warrant only a few years' worth of raises. Double my salary
well above $150k+ (I'm not in the US) and I'd consider it. They'll have to pry
my precious code from my cold, dead hands. I'm in my early 30s now; perhaps my
preference will change as I approach my 40s, but for now I'd rather be a rock
star in my field than be just another manager whose team hates him because he
has no real control to change the company's politics.

~~~
bkor
IMO manager = make more money but put in way more time. Meaning, deal with the
questions from higher management, prepare all the various performance
meetings, etc. Especially sudden highly important tasks are fun. Or
announcements that happen on e.g. Monday and you get your information Friday
late. This leading to having to review everything during the weekend.

It seems some people care more about the total salary than what they earn vs
time invested.

PS: Regarding your team hating you: Decide for yourself how you manage. I
prefer the honest types who just say "company decided and we just have to deal
with it". If you start pretending you totally agree with things you'll not be
able to give good answers to the various questions and people will think that
you have no clue.

~~~
overgryphon
Choosing to take on management roles doesn't mean someone cares more about
total salary than time earned. They probably just care more about team culture
and mentorship.

~~~
developer1
I suspect common reasons for taking on a low-level management role include a)
developer burn-out, time to move up and not have to code all the time; b)
desire for more power (whether for egotistical reasons or in the hope of
effecting positive change in a position of power); and c) a stepping stone to
further levels of management where the salary upgrade actually becomes
tangible.

I don't disdain competent developers who move up, I just personally don't
understand it - yet. I imagine the time will come where I've had my fill of
programming. Even if I don't burn out, I expect I will reach that age where I
begin to feel that younger developers and management are dismissive of my
abilities, and it will be the only escape into a role where I can earn back
some respect. :)

------
chad_strategic
This article is funny...

Object Oriented leadership? OOL

Human Emotion Design Patterns.

Functional Emotions...

There is no leadership in Tech / Dev. (Don't worry there is much in other
parts of the business world and certainly not in the banking / finance realm.)
That's why they invented Agile. The business side needed to make sure the tech
side was "doing" what they could quantify.

Sure you can read from a book, but leadership is one of the few
characteristics that has to be experienced in combination with self
evaluation, in what this author is doing.

Real leaders don't shy away from a challenge...

------
mbostleman
Financial management, hiring/firing, KPIs, 360 reviews - none of these things
are lead developer responsibilities imo. That's management work. I prefer the
two be separated. In my experience, the last person you want leading
development is a manager or, worse yet, a good lead developer that is shoe-
horned (probably unwillingly) in to management. Maybe that will be something
else he learns soon :)

------
openfuture
Do you know of more initiatives like PHPmentoring? (which he mentions in the
article). I like knowing about all the options :)

Thanks

P.S.

While it is helpful to see suggestions on how his perspective could still be
improved its also good to know which of the things he said you consider good
advice. I feel like people have a tendency to only speak out when they see
flaws.

------
meesterdude
Very insightful! all things I'm eager to tackle when I land a lead position. I
don't mind writing less code if it means I can facilitate larger movements.

Although as others have noted this has a lot of management roles mixed in as
well, which is more than what a lead dev might typically do.

------
MrGando
I think he's more manager than team/tech lead. Team/Tech leads code quite a
bit as far as I know

~~~
lox
Yeah, although they shouldn't. If you lead a team your job is to be a force
multiplier, not an individual contributor.

~~~
MrGando
You can be both.

------
daxfohl
Erm, what _were_ you prepared for?

