
Ask HN: How do you manage and structure a team? - losingcontrol
Here&#x27;s a question to managers and startup and founders out there, but first a bit of context on my situation:<p>We are a small team that has recently created. As such, we&#x27;ve been given a fair amount of control over how the team are structured. This involves everything from how we work, how we progress in our careers and how much we are paid. While this is a really nice position to be in, it raises a number of concerns.<p>In an ideal world, I believe that a flat structure would be best. We are all technical people, working on a series of short (months in length) projects that tend to be self contained. There is no immediate need of a hierarchy. But in this case, how do you define “progression”?, both how people are paid, and their “title” within the group.<p>To get around this, the obvious answer is a well defined “hierarchy”. Progression and pay are well defined ahead of time and everyone knows how it works. The problem is that we have only just been created, and as such the variance of the pay within the group is big. Initially this isn&#x27;t an issue – we all agreed to be here for the amount we are paid, but over time it can become an issue: without well defined progression, this issue of separate pay will become an issue and half the group will leave.<p>Another problem (and a separate one, one that we will also need to address) is that judging the direct merit of each others work is hard. Mostly because the work is a spectrum between “core” work, that is required, and “new features” which can bring in a large profit (or fail), and disentangling the two is hard.<p>There has to be somewhere in between these two position. And we can&#x27;t be the first to find ourselves in this position, and I&#x27;d like to here from others who have been here: 
- What worked well?
- What worked badly?
- What would you have done differently?
======
johnorourke
Read "Peopleware". Seriously, every page was written with you in mind.

Next, if you (as developers naturally do) struggle with the idea of
management, structure and order, read "The E-Myth Revisited".

Peopleware TL;DR: Good teams are united by a strongly defined purpose (eg. get
X defined and tests written by date X), and that is almost NEVER the same as
the goals of the business (which is to make money). Don't create internal
competition; overtime kills productivity; physical/mental space allows
creativity; interruptions are deadly.

The E-Myth TL;DR: Aimed at small business owners, but as a team lead you're
effectively running a business, and the rest of the company is your customer.
It's a mere 5 hour read... JFDI :)

And if you're feeling really bookish, "The Mythical Man Month" \- if you're
under 50 this will shock you, because you'll realise that software in 1970 had
the exact same problems that we do in 2015.

~~~
phamilton
The biggest takeaway from The E-Myth for me as a software engineer was the
idea of making a job easy enough for the least qualified individual to do it.
The example they use is how to train completely untalented 15-year-olds to
make burgers at McDonalds. McDonalds doesn't need to hire chefs.

In software engineering, I've seen teams look for years for a candidate with X
years of experience in technology Y. In many cases, you don't need an expert,
you just need a smart person.

Build up a library of books/articles as well as sample code and exercises.
Then hire smart people rather than experienced people. We had a git repo with
exercises in functional programming and scala along with unit tests and day
one involved checking it out and getting started.

Also, simple code is more accessible to the "least qualified individual". You
may sacrifice performance, but you will be able to scale more effectively as
an organization.

~~~
interesting_att
Really interesting point: Sacrificing short term performance for long term
efficiency

~~~
phamilton
Someone once told me that the key to scaling is tolerating inefficiency.

Example: Instead of a front end team and a backend team, have two full stack
teams. If they are working on similar parts of the codebase, don't stop them.
It's better for both teams to build the same piece of functionality and throw
one away than to have one team dependent on the other. Many teams grind to a
halt when they say "We could build this in a week, but let's let the other
team do it because it will only take them a day or two."

------
jedberg
Have each person go out and interview for another job once a year. Match their
best offer if you think they're worth it, or don't and let them go be happy
elsewhere.

This was basically what we did at Netflix, but since there were a lot of
people not everyone had to interview. We had a pretty good idea of what
everyone could get elsewhere and then we just paid them that much.

But we were all encouraged to interview elsewhere to learn our personal market
and find out if there were other jobs out that that we would like more. It
wasn't good for anyone to have you stick around doing a job you don't love.

~~~
advertising
^^^ this

------
jeremymcanally
> In an ideal world, I believe that a flat structure would be best.

"Any sufficiently complicated company w/o management contains an ad hoc,
informally-specified, bug-ridden, slow implementation of management." —
@wycats

In my experience, that's held true nearly every time I've worked in a flat
team or know someone who has (anecdotal, I know).

Point is: figure it out now and you'll thank yourselves later. Starting flat
and changing it later will just lead to more pain and damage to the team
cohesion and structure.

~~~
joesmo
Listen to this guy and @wycats. This has been my experience also. Flat
structures are horrible.

~~~
icebraining
Are flat structures horrible, or are horrible flat structures horrible? Which
systems have you experienced?

~~~
Spooky23
Flat structures are really project based orgs. They work fine if you are in
fact working on projects.

When the org grows and operational/day to day work and process start to
appear, flat orgs falter more often than not. Someone needs to be accountable
for critical things, and whomever ends up in charge of the most critical thing
ends up being "more equal" than everyone else.

~~~
icebraining
Why are flat structures necessarily project based?

I'm sorry to appear argumentative, but this is an area where we as tech
workers have a great opportunity to explore alternatives to the dominant
system of command-and-control, since we have small companies which are already
tasked with trying new stuff, and what I'm seeing is blanket rejection based
on a few (often misguided and naive) tries.

I'm not an expert either, but I've seen many small organizations as a grew up
(specifically, theatre groups), and while they had project (plays) based
distribution of tasks, some also managed the other stuff (like finances and
requests of grants) without creating an hierarchy or putting those people in
any way in charge.

~~~
Spooky23
IMO, the project-based nature of a flat org is essential because the project
is a unifying mission with regular updates and well-understood outcomes
(project milestones).

Small orgs are different because motivated people can self-organize. A small
theatre company or neighborhood block party committee can self organize
because the core cadre of a half dozen people take care of the finances,
grants, etc. Even in those cases, someone is at least nominally in charge --
an individual needs to sign checks, apply for grants, hold the cash, etc.

I've lived this at least a dozen times, in a mid/late stage startup, F500
company, and sprawling government bureaucracy. The story is _always_ the same.
New business units emerge with a guy in charge and a nimble team of <10
people. They achieve success and grow. Problems start around 10-15 people
because folks are focused and cannot productively communicate across the
group. Leaders emerge and work out differences. The next point of resistance
in around 25-30 people -- the lack of explicit authority undermines the
emergent leaders. Everything breaks at 40-50 people unless there is an
established chain of command.

There may be a way to tweak these things and make it work, but it takes
special skills/knowledge/instincts that aren't obvious to people. Special
things are hard to repeat, and business relies on repeatable process.

IMO, there are a couple of ways that flat orgs can work. The most obvious is
where the work is delivering unkilled/skilled tasks. A plumbing company has a
dispatcher who sends out plumbers. A consulting company has salesmen called
Vice Presidents, Project Managers and dispatchers. No hierarchy.

I think the other type of org is a co-op type arrangement. Coops have some
hierarchy, but the power structure is elected vs. appointed which changes the
dynamic.

------
andersthue
The thing about flat structures and group dynamics is that if nobody is
appointed to be team lead, then an informal leader will be chosen.

This is a well researched fact. The flat structure without a leader normally
leads to a official goal of the group (finishing the task) and an unspoken
unofficial goal that the unofficial leader is setting by example and retoric.

Everyone needs someone to follow on a team, someone who sets the standard,
leads the way and defend the team - even in the most flat structured companies
I have encountered this has been true.

If you want a methodology/way to run the team as fair and autonomous as
possible, read Daniel Pink's book Drive - it explains what is needed to make
people happy in their work.

If you do not want to figure your method out by yourself, steal my method
called TimeBlock, it empowers the employees and gives them Purpose, Autonomy
and Mastery (ping me if you want one on one help with it)

~~~
shiyuanis
I completely agree with this. From running small organizations and teams and
then later my own businesses, I've learned that "no management" and an
"anything goes" mentality enables dominant personalities within the group and
the dominant power structures in society to replicate itself within your
organization. That's how you end up with all guy teams cracking jokes about
hookers while they're working and thinking that's acceptable. Not good. I
always want to set the culture myself, so that it's thoughtful and purposeful.

It sounds like you're concerned not just about getting things done but about
making sure that duties and compensation is fair. I'd lay out a range for
compensation and clearly outline duties for each position. The younger your
company is, the more wiggle room you need in duties because things change
quickly. But spelling things out and communicating them clearly to folks gives
them an opportunity to tell you if they think the duties to compensation ratio
is unfair or let you know that duties have crept up more than they can handle.

And I'd set up regular reviews and check ins. (Like, once every other month).

I'm all about that structure. No structure = no expectations = no way for
people to succeed within their jobs.

------
Ingon
One of the main things I've noticed is that every person is different and
therefore every team is different. Also teams evolve over time, so even when
compromised by the same people you can look at them differently "each" day.

I think the management should start with observing and listening. By paying
attention to what's going on in the team you can start influencing it by
praising beneficial (e.g. helping to meat the team goals) behaviors and
preventing the un-beneficial ones. Then of course, when you have expectations
from people, its best to get them on board as soon as possible and not leave
them wonder why they've been praised and why "punished". Providing clear
feedback as soon as possible seems to really work.

Another big thing you should watch out is what kind of people you've got on
your team - intrinsically driven or externally driven. The more intrinsically
driven people you have the less structure you need - its more about setting
goals for them and getting out of their way. The externally driven people
require far more structure and management in order to make them meet their
goals.

In the end, because things could change quite frequently, I think the most
important thing is communication - clearly and as often as possible, go over
what we are trying to achieve and what could we do better to achieve that
faster. For instance, although I'm hugely internally motivated, I'm really
happy when I meet my "boss" and we get through all the things we are doing
properly and what things we are not. Not having this kind of meeting for a
long time is actually really upsetting.

Of course this scratches only the surface of what management is. Good luck on
making an awesome team.

------
bane
It sounds like where you are doesn't require much structure for organizing
work...yet.

What you need is a way of tracking other's work for merit:

\- Set goals with each person, those goals must align with what the company's
goals are. Bonus, if everybody's goals don't fill all of the corporate goals,
it means you need to think about hiring. If you have over representation in
some goals, it means you're overstaffed in that area and need to work on
moving people and developing them to fill in gaps.

\- At six months see how they're doing in meeting those goals.

\- At 12 months, do a full review.

\- Set up a sliding pay-raise system.

\--If they meet all their goals, they get some agreed upon number.

\--If they miss a few, they get less.

\-- If they miss half (or whatever you specify), they get nothing and an
improvement plan that's checked on after 30-60 and 90 days with the normal six
month review deciding if they can stay.

\-- If they miss more than half, time to think about parting ways.

\-- If they exceed their goals, give them a bonus (not an extra pay raise
since those can live forever) and then think about giving them tougher goals
next time.

As for work structure, you must have a hierarchy, otherwise one will develop
naturally and it most likely won't be aligned with the needs of the business.
This is what humans do in groups of 2 or more, there's no getting around it.
Just take a person with some leadership skills and put them in charge of
managing a group of related tasks, and reporting up how things are going not
going. That extra responsibility also needs to be rewarded.

One options, make people task managers instead of people managers. They own
the task and when its done, they move on to other work or get another task to
manage. This can help you maintain the feeling of "flatness" while creating
opportunities for different individuals to get experience being in charge of
things.

~~~
jevanish
If you're suggesting the OKR system of setting goals that align individual and
company, that seems like a good idea, but not when tied financially.

If OP has a small, growing business, this seems impractical. I've worked at
startups that tried this and even a quarterly bonus failed.

Why? Because things change too much. Despite their best efforts, what we
thought was "The Most Important Thing" at the start of quarter ended up being
slightly or sometimes completely different. This threw the whole bonus system
off.

Now, since I was counting on those bonuses, I always immediately brought up
any conflicts; I was happy to make the change that was best for the company,
but didn't want to be financially penalized for it.

Also consider what an earlier comment brought up: Autonomy, Mastery, and
Purpose (Dan Pink's Drive thesis). Financial incentives aren't the best
options in creative roles.

------
rebootthesystem
No. You need a leader. A flat structure will eventually create problems. And
they will be hard to solve. Or you could lose a good chunk of the team due to
the lack of direction and management.

The following will not be perfect analogs, I offer them as thinking tools:

8 seat rowing shell: It's hard to think of a better example of a small group
of people with a well-defined purpose who train hard and execute hard towards
that goal. Yet, the boat has NINE people on it. The ninth peeson is there to
keep the team going in the right direction and at the right pace.

A leader is important and he/she does not have to be dictatorial to be
effective.

The second example is more of a homework exercise:

Watch a dozen (or more) episodes of "Kitchen Nightmares" with Gordon Ramsay.
Think about the most common issues leading to failure. Write a one page note
advising your team on how to avoid failure.

The third and final is also homework:

Watch a dozen (or more) episodes of "The Profit" with Marcus Lemonis and write
a short conclusion as above.

Business isn't hard if you understand there are commonalities between making
burgers, manufacturing baseball bats and, yes, making software. At the core
they are the same. Above that they have specialized processes that are aligned
with what the business is about. The operating approach between knowledge
workers and assembly line workers naturally diverges in a lot of areas.

Think of it as the OS kernel versus abstraction layers above it. The same
kernel functions are pretty much required in order to build a successful
system. That's where you start. Same with business.

------
lowsypunk
In business school, progression purportedly provides three values to the
employee: authority, recognition, and pay. These values benefit the company by
motivating the employee to excel and by redirecting power based on merit. The
latter two of the three are immediately still possible in a flat organization.
Give people recognition for their accomplishments, and pay them more.
Recognition can be formal (certificates, badges, etc) and informal (shout outs
in meetings, parties, etc).

When it comes to authority, we must first examine whether past success
determines future success in this industry. Many flat organizations are new
companies, trying to create new products in unproven markets. For them, there
may no best practices, in which case flat teams can actually benefit from
having more discussion (even conflict) before decisions are made (especially
if they agree to try disparate ideas quickly and cheaply to resolve the
conflict). If this is the case, losing employees who cannot be motivated
without looking forward to authority is good for the business.

If there is demonstrated evidence that the industry is mature enough that
success is likely to be repeated by those who have implemented certain
strategies and tactics in the past, the organization should yield authority to
these individuals. Even when someone becomes someone else's boss, the firm can
retain a culture and feeling of being "flat". This is accomplished through
celebrating regular, open discussion across ranks. The tow biggest challenges
here are keeping performance evaluations objective despite expressed
differences in opinion (not discrediting your employees just because they have
challenged you) and maintaining a perception that the boss is "available",
even when the boss is objectively busy (when someone tries to walk to your
desk to chat while you're on the phone with an important client, how "flat"
can you be in the moment?).

------
kabouseng
There are no simple answers here, and it very much depends on the team
members, their history working together, their professionalism and maturity.

For junior / inexperienced teams a much more formal structure will have to be
set in place, with lots of management input.

For more mature team members or teams who have a longer history working
together less structure is required and perhaps even preferred because formal
structure just tend to get in the way of getting things done.

Lastly be careful of trying to evaluate the merit of everyone's individual
contribution. You get different contributor types, where you get the loner
archetype who creates massive amounts of code but doesn't communicate with the
rest of the team enough, or the team player who maybe don't write the same
amounts of LOC's, but keeps your team cohesion healthy and happy.

You need all different types of contributors on a successful team, rather
measure the teams output and reward everyone if the team perform. With the
exception that if the team starts complaining about a single slacker in the
team you address the issue.

------
jevanish
It sounds like you're hitting a wall or getting close to a wall many others
have hit as they grow. The company changes dramatically as it happens. One of
the big milestones is around 25 employees:
[https://getlighthouse.com/blog/company-growth-everything-
bre...](https://getlighthouse.com/blog/company-growth-everything-
breaks-25-employees/) You have to adapt to that or you'll grow into
dysfunction unintentionally.

If you want to learn how one of the legends, Andy Grove of Intel, does it,
then I highly recommend "High Output Management" to think through some of
those challenges. Check Twitter and you'll see Keith Rabois, Marc Andreesen,
Ben Horowitz, Ryan Sarver, and many others swear by it. Horowitz's "Hard Thing
About Hard Things" is also great, but a bit more haphazard in how it covers
topics.

------
borland
> judging the direct merit of each others work is hard. Mostly because the
> work is a spectrum between “core” work, that is required, and “new features”

You can't implement the new features without the core work to provide a
foundation. Don't judge performance by financial impact of the code, judge
performance based on peer review. If you've got 2 programmers, you'll want
them to be doing things like design reviews and code reviews, and as such
they'll be able to provide a reasonable assessment of how well they think
their peers are doing. Whether each bit of work itself needs doing in the
first place? well you need a signoff/approval process. Whether that's a
manager, or simply a chat with your peers - the act of convincing others that
yes I do need to implement this core XYZ instead of feature Q is an important
one

------
spazmaster
Have a look at Holacracy for interesting ways in how to structure teams and at
the same time gearing up for continuous change. It's a very different approach
than creating hierarchy, but it's not completely flat either.

[http://www.holacracy.org/](http://www.holacracy.org/) and
[http://www.responsive.org/](http://www.responsive.org/) for more interesting
philosophies surrounding movements like Holacracy.

(We have a team of 10 people and are thinking about adopting Holacracy).

~~~
jevanish
I'd be careful with holacracy. There hasn't exactly been glowing successes in
the press lately: 16% of Zappos's company quit over it, Buffer has completely
abandoned it after a very public foray into it, and I saw a talk by the HR
people at Medium and they've had to make significant adjustments to fit (for
instance having one on ones even though there aren't technically managers).

------
barking
I listened to an interview with Joel Spolsky from 2011. He made some
interesting points about this. If you have 3 people you have 3 lines of one to
one communications. If you have 4 developers you have 6 lines and it starts
getting difficult So what he prefers is to have one person responsible for all
communications. Everyone communicates through this person and by the time that
person has 5 developers to communicate with it's a full time job.

~~~
jacques_chester
Spolsky was relaying the observation which was first made by Fred Brooks in
_The Mythical Man-Month_. There's a good diagram in McConnell's _Rapid
Development_ when he discusses it.

~~~
jevanish
This image is probably what you're looking for:
[https://getlighthouse.com/blog/wp-
content/uploads/2015/07/li...](https://getlighthouse.com/blog/wp-
content/uploads/2015/07/lines-of-communication-stackoverflow.png)

Via: "Developing Leaders: What To Do When Your Team Grows Too Big"
[https://getlighthouse.com/blog/developing-leaders-team-
grows...](https://getlighthouse.com/blog/developing-leaders-team-grows-big/)

------
advertising
Ran a team of three people that grew to six. It's easier when smaller. Even
just with a couple more people, the team of six created communication issues.
In the end running the team created as much work as having more people to do
the work saved.

Six is still small time, just the experience I can speak from.

I would have communicated more. And most people need a boss, or a leader.

------
rrecuero
I recommend reading The Future of Management by Gary Hamel. We have all
adopted the dogma that hierarchical management is better without questioning
it. Is it really? Companies like Whole Foods, W.L Gore, Valve or even Google
are great examples that flat hierarchies are attainable.

------
epicureanideal
I think you should be able to find a way to connect the core work to the
feature work. You can point to what feature work the core work enabled and
share credit for that feature with the person who did the less visible part.

------
speek
I've also had really good luck setting up + managing one-on-ones using
Lighthouse ([http://getlighthouse.com](http://getlighthouse.com)).

------
PaulHoule
It depends hugely on what you are trying to do.

You are definitely right to be thinking in terms of a team, because the myth
of individual performance is damaging in so many ways.

------
guybrushT
_There is no immediate need of a hierarchy._

Depending on the size of the team, this is a good thing. As long as you have
one "alpha", a designated or undesignated person who makes a call when
contentious views are blocking progress.

 _I believe that a flat structure would be best_ You'd want to be careful of
premature optimization here. I know what you are trying to get at (i.e.
ensuring that you are setting up titles and roles that people can grow into),
but this may not be the right time to do it.

Any structure is good, bad, best depending on the situation you are in, the
size of the group, the problem you are trying to solve etc. The point is not
to see hierarchy & structure as inhenrently good or bad -- but to work back
from what you are trying to accomplish to the structure you need. Lets say you
were trying to organize a 6 month expedition to a remote area with a group of
people that you just met. How would you or this group go about it? I don't
think you'd setup titles or hierarchy -- you'd probably go with "role
clarity", and doing things that engender "excellence" in their respective
tasks.

In a startup, one expects an organization to be driven by passion, creativity
and very little structure. This is an important part of why people are there.
Traditional forms of motivation or organization often don't work very well
(e.g. hierarchy money, title or fear). Once the group is large, then there are
companies that go for military style "command & control" structures. Even
military is organized differently during war time and peace time. This comes
back to the context of your particular situation & what you are trying to do.
Are you in war time or peace time? :)

The most important thing is that you have a process that everybody understands
-- you may never codify that process, but everyone on the team should know
that it is there. And the process is: "To get things done & make a
difference". What is the best way to do this?

You want to give a sense of progression, via money & title etc. These are good
things, but there are more levers you can pull. In a small group, it is
obvious who is kicking-ass and who isn't. You should let them, create an
atmosphere first where they can do this -- and then, when they are. Talk to
them about what they want. Do they want to run a team? Do they want more
money? Do they want a more senior title? Do they want more free time? Do they
want more flexibility? Do they want more responsibility (e.g. looking at 3
workstreams, instead of one)? Your answers will evolve. But don't take your
eye off the prize -- and the prize is to create an atmosphere where people can
excel.

 _Judging merit_ You make this sound hard, but is it? In a small group, isn't
it obvious when someone is kicking ass? The problem you are worrying about is
that when somoene is kicking-ass, how do I make sure they are rewarded, so
that they continue kicking ass. I would say, let people kick-ass first, and
understand why they are -- lets say they inherently love 'solving problems',
then give them problems to solve that honors & respects their talents.

------
beachstartup
all i can say is two things:

1\. someone has to be the boss, the person who makes the final decision for
the group. it may not always be their own first choice, but after taking input
from the group, the decision must be made, and followed. finding this person
is hard because they have to override their own opinion sometimes. although
for the right group leader, the best decision for the group/goals _is_ their
first choice by definition.

2\. meet every single day first thing in the morning and go over open issues,
blockers, eta, and priorities. note that these are not problem solving
sessions, just identification sessions. you can call this agile, a stand-up, a
ticket review, whatever. just makes sure it happens. once you get into the
groove you can usually keep it to 15 minutes. every effective organization
i've been in does this or something very similar (maybe every other day). i've
seen some small groups do this 2x a day. once or twice a week is not often
enough.

you will find that doing this actually reduces the meeting workload overall,
especially when combined with #1.

~~~
SyneRyder
> meet every single day first thing in the morning and go over open issues,
> blockers, eta, and priorities... every effective organization i've been in
> does this

I was going to counter this and say not everyone works best with daily
meetings... until I saw your username, "Beach Startup"? Because remote work is
the counter-example I would have given. Do you work remotely / from a beach &
still have these synchronous morning meetings every day?

I agree it's important for team members to always be aware of open issues /
blockers / eta / priorities, but I'd suggest that's what project management
software is for. Team members can work in their own timezones / schedule and
still check the issues / priorities themselves daily. Curious to hear if your
experience is different.

~~~
beachstartup
i view the perk of remoteness and a flexible schedule as a trade off to be
more rigorous about the few times you actually do have structured
communications. you take the opposite view.

~~~
SyneRyder
Fascinating, I genuinely expected asynchronous communication to be almost
necessary when working remotely, especially across timezones. Thanks for the
great response!

