Hacker News new | past | comments | ask | show | jobs | submit login
Ask HN: How do you manage and structure a team?
136 points by losingcontrol on Sept 20, 2015 | hide | past | web | favorite | 62 comments
Here's a question to managers and startup and founders out there, but first a bit of context on my situation:

We are a small team that has recently created. As such, we'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.

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.

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'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.

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.

There has to be somewhere in between these two position. And we can't be the first to find ourselves in this position, and I'd like to here from others who have been here: - What worked well? - What worked badly? - What would you have done differently?




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.


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.


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


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."


Wouldn't the equivalent of burger flipping be Java development, perhaps in a standardized framework ?


In one sense you are correct. And many companies have found great success in that model.

In another sense, burger flipping doesn't require certifications.


I second the recommendation for MM-M, after recently reading it. You may find the chapters around how to structure a team to be interesting. Here's my review (posted elsewhere):

----

I decided to give MM-M a read, after seeing it repeatedly listed as one of the classics of the fledgling - as the book maintains - field of software “engineering”. Despite a few dry chapters extensively detailing the development of OS/360, the book holds up remarkably well for being forty years old. Indeed, many of its central, oft-repeated development aphorisms still hold value. Unfortunately, its advocacy for extensive and exhaustive planning and documentation cycles screams “waterfall”, and muddies what is otherwise - I think - a number of worthwhile recommendations:

1. Avoid the second-system effect by being ruthlessly practical

2. Build a prototype and throw it away

3. The essence of programming has an irreducible complexity

Aside from these, I noted with great interest Brooks’ suggested team structure which he refers to as a surgical team: 6-7 people in highly stratified, and complimentary roles, led principally by a “surgeon”-type chief architect. I’ve only worked within relatively flat team structures up to this point, typically set up in junior/senior relationships. Since this is a less frequently cited recommendation in the book, I’m curious to know if it has been implemented with any success.

Finally, this suggestion is tantilizing:

As a discipline, we need an extended information theory that quantifies the information content of static structures, just as Shannon’s theory does for communicated streams.


What do you mean by "build a prototype and throw it away", exactly? I'm having trouble discerning the meaning behind the image.


Further information from the MM-M wiki article:

https://en.wikipedia.org/wiki/The_Mythical_Man-Month#The_pil...

The lesson is basically, when you're designing a new system or product - make one with the knowledge that you're going to scrap and it start over. The value in doing so is that you expose flaws and design challenges that you can't anticipate through the speculation that occurs before you've actually started.


This is a very good reply.

Another really good book about management is called _First, Break All The Rules: What The Worlds Greatest Managers Do Differently_ by Marcus Buckingham of Gallup Polls.

TL;DR: Different things work for different people, figure out what works for your employees and do that.

My big recommendation is that for kids, you reward effort, for adults, you reward for results.


This is an excellent reply.


Agree. Excellent reply.


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.


^^^ this


> 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.


There are two structures in a company: the management/decision structure & the communication structure. The management structure should be hierarchical. The communication structure should be flat. Make sure you have both!


Preference for flat structure is largely a product of bad management experiences


Why are bad management experiences the norm? There's a good reason for the desire for flat structures. My question is whether they can be made to work; I think they can.


Bad management is the norm, especially in Silicon Valley/Startups because:

1) No training for managers. 2) No measurement of managers against what actually makes a good manager (ie- only rewarded for results, ignoring if your team hates you and is quitting left and right). 3) First time Founders may not have had great role models or training themselves so they won't set a great example either. 4) First time managers are common because you were an early employee or around longer, so I guess you should manage. 5) Misaligned incentives: the only way to get a raise is to go into management 6) Being a manager isn't for everyone, but few companies make it safe to go back after 7) Turnover is tolerated more in the Valley than other places which can hide management problems others companies could never afford (it costs about 2/3rds of a salary to replace someone).

Re: Being able to be flat sounds great, but at scale creates a lot of challenges when you need decisions made and you don't all fit in a conference room anymore. Having someone who can make a final call (and ideally does take input from everyone involved) is more efficient than having 50+ people all moving in independent directions.

[2] Google Questions for Good Management https://getlighthouse.com/blog/google-management/ [5] [6] Why people take management jobs and shouldn't https://getlighthouse.com/blog/bad-manager/ [7] Why it costs over $65,000 to replace an employee https://www.linkedin.com/pulse/hidden-costs-replacing-employ...


I'd add to this, someone is more likely to be promoted if they are great at managing up, than managing down. Ideally you would have someone that does both well, or is stronger on managing down. I'm sure we're all seen that weaker results/contribution employee that seems to fail upwards.

I wonder if companies have tried doing promotions via a 360 selection rather than managers putting in their choice. It would be interesting to see people from lower ranks push for promotion and how this effects dynamics/results if weighted in the decision? Might work or just be a popularity contest.... I guess like everything it would be more about execution than idea.


Great added point, Gustomaximus. If you don't create a good feedback loop in your company, then people at the top making the final call for a promotion are going to go on the only info they have: their personal experience.

Deloitte got rid of performance reviews recently and one of the things they replaced it with was asking managers who they thought was ready for promotion and why. They also asked if you had to start a team over again, would you want this person on your team. I think all of those questions cut through the BS and are exactly the kinds of 360 questions you're suggesting.

Imagine a manager is up for a director role and each person they manage is anonymously asked "Would you work for them again if they were building a new team?" It could be a great way to understand how much people really like working for them.

Google actually does this with their questions every manager's teams are asked it affects compensation and promotions for managers:

1) My manager gives me actionable feedback that helps me improve my performance

2) My manager does not “micromanage” (i.e., get involved in details that should be handled at other levels).

3) My manager shows consideration for me as a person.

4) My manager regularly shares relevant information from his/her manager and senior leadership.

5) My manager has had a meaningful discussion with me about my career development in the past six months.

6) I would recommend my manager to other Googlers.

(More here: https://getlighthouse.com/blog/google-management/)


> Starting flat and changing it later will just lead to more pain and damage to the team cohesion and structure.

I totally agree with this. My company started with just 4 employees, and now that we have over 15. Three years later, we still struggle with defining management roles, because the original employees (including me!) have had many, sometimes overlapping roles dues to the small size. Now, it's difficult to really define roles and responsibilities because we are historically used to working free from any management from others.


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

That include companies with management as well. I have yet to work a place where the formal and informal management structure matched. They are usually correlated, sure, but they don't match. You have the manager that have raised to his level of incompetence that is generally ignored, people with a lot more to say than their position should indicate and people working across the company hierarchy in ways that the formal management structure does not suggest. I would in fact say that it is a requirement for a successful company to allow that to happen to some degree.


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


Flat as in completely amorphous teams are a management anti-pattern because (as the poster above describes) cliques will crystallize anyway and a balkanised, feudal pecking order emerges.

Flat as in shallow hierarchy, though, that can work well. My preferred team size is five, with a maximum of seven, because communication patterns grow factorially. Beyond seven, the leader is overburdened by admin.

Seven groups of five makes a 35-strong engineering team and can be stunningly agile and productive, especially if the duties of maintenance and support are rotated periodically.


Ideally the maintenance and support are part of each team's duties. You'll never be more motivated to do things right than when you have to maintain and support your own work.


Perfectly flat structures are horrible, but on the flip side, if you have too many layers between the people making the decisions and the people implementing the decisions you're playing one large game of telephone.

That's why I like mid-stage startups. Typically, everyone reports directly to a VP, who reports directly to the CEO. The CEO has a clear picture of the company, the VP has the clear picture of a single specific product and the engineers have clear direction.


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


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.


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.


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.


Non-horrible flat structures very quickly become neither. There's an old essay available online called "The Tyranny of Structurelessness" that talks about this.


I've read the essay, but regardless of its merits, it talks about unstructured organizations, not flat structures; hierarchy is just one of the possible structures you can use to avoid the problems she describes.


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)


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.


I just want to add to this - as a manager you need to take initiative and designate a leader when conflict arises

I had several months of constant arguing with a coworker about what amounted to mostly style issue (I found his adherence to the style-guide overly OCD and a giant waste of time)

However once the "boss" over ruled me and it was decided he's follow a stricter standard the issue was out of my hands, I was no longer responsible for the delays in deployment and to be honest I no longer really cared for the extra work.

You need to be clear about the chain of responsibility here. When it's two coworkers arguing it's just a matter of opinion.

PS: Don't underestimate you manager especially if they're experienced. The will have a lot fo insight if they are good. A lot of people are saying "Don't make it flat!!", but as long as you keep your boss in the loop - whatever organizational structure you bring you're still being "flat".


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.


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.


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.


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.


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?).


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.


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... 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.


> 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


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/ and 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).


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).


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.


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.


This image is probably what you're looking for: https://getlighthouse.com/blog/wp-content/uploads/2015/07/li...

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


do you have a link to this interview? sounds interesting.


hi, I should have posted a link, here it is: https://www.youtube.com/watch?v=NF8ZVB-v3IM


nice vid, thanks man :-)


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.


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.


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.


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


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.


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.


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.


> 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.


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.


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




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: