
You’re Not Managing a Team of Software Engineers, You’re Managing Writers - ohjeez
https://medium.com/coaching-notes/youre-not-managing-a-team-of-software-engineers-you-re-managing-a-team-of-writers-b263d3a10cc7
======
thinkingkong
No youre managing a team of software engineers, one skill they have is
writing.

The product isnt the text. The product is the entire system designed to keep
the text alive, functional, reasonably error free all in a relatively
unpredictable environment.

We definitely need to keep considering how other professions manage the
unpredictable nature of their work so we can learn. Im just not sure this
narrative suits that goal.

~~~
slededit
The uncomfortable fact is other professions treat their employees like cogs
(hiring booms then mass layoffs), or their customers like crap (ever wait an
hour for your set time appointment at the doctor?). The determining factor is
really the price of the professional.

Software development is in a real interesting situation as its transitioning
from a low status job to a high status one. As this progresses you'll see more
and more "the customer is always wrong" style blog posts. They are already
pretty common already.

~~~
jungler
I would liken any status in software to superstardom in sports. If you're in
demand for exactly the right thing, all the doors open. But if your real
calling is something with no extant "pro league", you are viewed as a hobbyist
without relevant skills.

Knowing 6502 assembly was a pretty sweet skillset, back in the day.

~~~
lsc
This is not my experience of the tech industry?

I'm not sure I've had any job in the last twenty years where I met all the
listed requirements.

My impression is that employers want some skill that it's sometimes possible
to puzzle together from (but is rarely directly stated in any reasonable way)
on the requirements list, then they want you to pass a poorly done faux IQ
test.

Then there's a bunch of social stuff, which I don't really understand well
enough to treat as anything but random noise. I mean, I can see that it's
there and that it's not random, but I can't really see how to change it to my
advantage.

Hiring is hard, and nobody, as far as I can tell, is any good at it. But being
too specific about what skills they want is not a problem I've personally
seen. (Not in the last 20 years in silicon valley, anyhow)

------
contingencies
_Niven 's First Law of Writing: Writers who write for other writers should
write letters._ \- Larry Niven, science fiction author (1989)

 _The writer is that person who, embarking upon her task, does not know what
to do._ \- Donald Barthelme

 _Summary of advice from writers: Advice from writers is useful, and not only
about naming. Writers have been at it for centuries; programming is merely
decades old. Also, their advice is better written. And funnier._ \- Peter
Hilton

... via
[http://github.com/globalcitizen/taoup](http://github.com/globalcitizen/taoup)

------
0x445442
Publisher(9am): Time for the morning scrum...

Author: Yesterday I worked on a few paragraphs where the antagonist was just
about ready to reveal to the protagonist his knowledge of the protagonist's
long lost brother. But I'm blocked on the historical research about Vietnam
POW camps. Hopefully, if my research assistant can run that down soon I can
move that paragraph from the unblocked column back to in progress. In the mean
time I'm pulling in the foot chase scene "story" but at this time I think both
these "stories" will carry over to next sprint.

Publisher: Hmmm, that's going to negatively affect your velocity.

------
ilovecaching
Managers shouldn't be writing code or architecting at all. A manager's job is
to manage people or a product. If it's people, she should be completely
focused on unblocking the engineers and keeping them out of meetings. If it's
the product, she should be completely focused on gathering the requirements
and constraints and communicating with the customer and getting estimates from
the engineers.

The architecture and implementation is a hidden detail for a manager. Either
the team lead, architect, or team as a whole should design and move on the
code.

~~~
poof131
The problem is the architecture is intertwined with the product is intertwined
with the people. Believing that these things can easily be broken apart is an
illusion. It’s how product believes one thing and engineers believe another,
resulting in quick hacks, missed deadlines, and a mediocre product, if it’s
released at all. Meanwhile the manager is a “people person”.

Teams need leadership, not three leaders. Dev managers should be able to
understand the architecture, and the product, and the team. Product advises on
the direction. Tech leads argue for the implementation. But the dev manager
needs to bring these things together and provide direction. Otherwise all
three people will just point fingers when the results suck—diffusion of
responsibility. Teams need leaders and leaders need to be accountable for
results.

~~~
ilovecaching
> Believing that these things can easily be broken apart is an illusion.

It works really well were I work. It's led to an extremely bottom up culture
were engineers want to stay forever, because they feel like management isn't
getting in their way or compromising technical decisions.

> Teams need leadership, not three leaders.

I'm not advocating for shared responsibility. What I'm advocating for is
separating responsibility such that each person knows exactly what they are
expected to deliver. The manager is expected to help his team perform and be
happy. The TPM is responsible for delivering the product the users want. The
tech team is responsibility for delivering a product as quickly as possible
that is maintainable and bug free and meets the requirements set by the TPM.

In your model, managers argue with the tech team, which causes people on the
tech team to quit or become frustrated because the managers can't understand
all of the details and still fulfill all their managerial duties.

> It’s how product believes one thing and engineers believe another

The role of the TPM is to make sure the tech team is building what the user
wants. the TPM should be synchronizing with the user and the tech team, making
sure this doesn't happen. It's their responsibility.

> Teams need leaders and leaders need to be accountable for results.

Agreed, teams need leaders who are focused on doing one thing, and one thing
well. They should not be backseat architecting or leading the technical
direction, unless they are the tech lead.

~~~
darkerside
I'm sure it works well in terms of making the engineers happy because it
sounds like the inmates are running the asylum. You're right that managers
should be dictating the what and not the how, but that doesn't mean they
shouldn't understand the "how" their report has chosen.

------
sonnyblarney
I prefer to think of them as carpenters.

Every carpentry job requires solving a lot of problems every day, and using a
variety of skills.

But carpenters don't think of themselves as divas or creatives.

In most cases, it's not nearly so romantic.

There are objectives, roadmaps, client needs: it's just a job. Put on your
hard hat, get your morning coffee and do it.

~~~
0x445442
I agree with everything you say but what bugs the living hell out of me is
this profession's infatuation the new shiny. That along with the almost
universal absence of any objective evidence that the new shiny will positively
effect the project's bottom line.

------
protomyth
I do wonder how a TV show runner of some experience would handle a software
production. There are a lot of moving parts that are not unlike what they deal
with.

~~~
21
There is no technical debt in TV production. That alone changes many things.
You don't need to care how you arrived at the result or how "maintainable" it
is.

~~~
AnimalMuppet
Plot debt? I could actually see that describing some shows...

~~~
XorNot
The Stargate SG-1 writers regretted the "3 shots from a zat-gun disintegrates"
thing, and had zat guns only ever hit stuff twice for the rest of the show
after they realized the mistake they'd made.

The problem was introduced to solve a plot issue in one episode - they needed
a way for the team to get rid of the bodies they were leaving behind on a
spaceship in one episode.

------
ilaksh
This article is a great example of the biggest problem with software
development management: they often fundamentally do not understand what
software engineering entails.

You can tell that he has caught on to a few aspects in terms of requiring
editing and creativity and not being able to plan everything ahead. But really
he doesn't understand the full extent of what programming involves. If he did
he would definitely not carry the writer metaphor so far.

A writer's output is natural language. Natural languages and programming
languages are extremely different things. Prose does not have strong and
brittle constraints on syntax and semantics that computer code does. Prose
does not create real systems with many moving parts that must align and
synchronize precisely.

If you could get a creative writer to sit down and just design a new type of
spacecraft engine by using his creative powers like a science fiction
exercise, then the metaphor would work. But engineers have to make systems
that are completely detailed, exacting, follow the laws of physics and harness
them in intricate ways. Software engineers are often essentially doing
research on new systems or new ways to combine systems.

If at all possible, get an experienced programmer to act as a manager for
programmers. A programmer would not describe it as simply writing.

~~~
shanghaiaway
Software developers cannot sit down and design a new type of spacecraft
engine.

~~~
lovich
That metaphor seemed like it was trying to show equivalent complexity, not
that the jobs were interchangeable.

Engineers on a spacecraft needing to know that at a certain temperature a
material contracts which changes the friction coefficient it has and increases
the heat generated until two moving parts melt, seems to have the same
equivalence as knowing that at a certain rate of incoming messages your cache
technology starts hitting a race condition where messages are double sent and
now the downstream work is duplicated but not able to be correlated.

All of this is different from ambiguous wording in natural language, where the
ambiguity might even be the intent.

~~~
abduhl
Thermal contraction would typically not change a particular part/material’s
coefficient of friction but rather would potentially decreasing acting normal
force. Friction is reduced because contact decreases not because some material
characteristic changes.

Pedantic maybe, but it does reiterate the point that a software dev couldn’t
design a spacecraft.

~~~
lovich
I think you may be missing the point. I was trying to give an example of
complexity, not trying to prove that a software engineer could casually walk
up and design a spaceship.

The OP's point was that both types of engineering are of similar complexity
when contrasted to writing in a natural language

------
alexandercrohde
I think it's a fine analogy. But the author doesn't go far enough. My thoughts
here:
[https://blog.alexrohde.com/archives/432](https://blog.alexrohde.com/archives/432)

------
teunispeters
I have found that a lot of the skills to do with writing effectively,
professionally and reliably also apply to writing (and maintaining) software.
It's not to say they're the same discipline, but they're closer than - say -
electronics engineering.

But then a lot of disciplines are also assisted by having more writing skills
as well.

------
GoToRO
You should not manage anything unless you yourself did that job successfully
for 10 years.

~~~
samatman
Best not build anything that didn't exist ten years ago then.

~~~
corpMaverick
Think of it as: "Don't manage software engineers unless you were a software
engineer for X years"

