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.

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.

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

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

----

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.

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.

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

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

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

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

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.

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.

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.

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.

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.

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.

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.

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)

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

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.

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

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.

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

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.

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.

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

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

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

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.

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

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.

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.

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.