Hacker Newsnew | past | comments | ask | show | jobs | submitlogin
Ask HN: What is your company architecture?
11 points by donutdan4114 on May 31, 2013 | hide | past | favorite | 6 comments
The company I work for is going through some big shifts right now. Changing of department heads and structures, etc.

It is a web development agency, with client services, project management, development, and some office admins. I am curious what structures you guys have experience with.

What works well? What doesn't work? How many managers are there, what are their jobs? What is the reporting structure like, who reports to who? Who is accountable for what? Processes that work? Scrum, agile, sprints, Kanban, JIT, etc?

Other thoughts welcome!



Professional services. Flat. Partner team (Dave, Jeremy, and I) with Dave as President. 3 offices (NYC, Chicago, SF). Practice managers for each office help manage the schedule, backstop client concerns, stuff like that. Lots of ongoing projects, each led by a senior team member. Partner team and practice managers all deliver work alongside consultants. Supporting team for project management, for finance, for IT, and for development.

Some functional divisions of work; for instance, I run recruiting, and a team of consultants runs research and judges bonuses for developing tools or writing papers. But mostly, deliberately flat.


Here are a barrage of further questions that I hope you don't find too annoying:

Do you assign specific teams to each project? I assume project leader to project is one-to-many (since you said senior member); is project manager to project one-to-one? How many consultants are typically assigned to a project? Are developers assigned to specific projects from the start or do project managers send requests to developers on an as-needed basis? If it's the latter, do requests get sent to some sort of development leader/manager type or do project managers ask around to see which developers have the bandwidth for their project?

Also, and this isn't particularly related to structure, but how do sales work in your organization? Do the partners handle it for the most part?

I'm not asking these questions merely to annoy you; they apply to the business I am in the process of building. (So far, we've got a flat partner team of three and a single part-time employee. We're experimenting with a contracted salesperson, which has been working surprisingly well until now.)


Yes, 1 team 1 project (no overlap, every project is full-time). Project lead is 1:1 too. Practice managers are 1:many, but aren't intimately involved in delivery. Projects generally rotate among staff; staff aren't permanently allocated to clients. Practice managers collaborate with partners and project manager to work out the schedule. We book pretty far in advance.

We don't have salespeople.


Thank you.


Here's what you do (IMVHO):

Step 1: Broadly define isolated units of work. This can be per project, per customer, per account, per whatever. An isolated continuous effort can also be called a unit of work (for example lead generation, sales etc.) The underlying idea here is to define teams. These will be cross-functional teams (programmers, designers, testers, marketers, managers, analysts etc. all put in one team).

Completion criteria:

-- You have defined all the activities your organization does -- You have a fairly good idea who does them. It is okay if a small minority of people are part of two or more teams.

Step 2: These teams will largely be self managed. Company does not tell them how the work. Instead let the team decide. The team must be answerable to itself. And make sure your team has mentors who understand the concept of self-management and self-accountability.

Simplest example is the morning standup / scrum meeting. For instance in my team every morning at 10 am everybody shows up an a specific spot in our office. The last person to arrive starts the meeting by telling the rest of the team what he did yesterday, what he did today, if he needs any help in his activity. Then the next person gives the team and so on. At the end, everyone in the team has a rough grasp of what's been going on and what they will work on today.

As a lazy slacker, I am pressured to work because I am answerable to my team. As an egoic fool, I would like to accomplish a lot because I get to brag to my team.

Step 3: Backlog. Always have a prioritized list of what each team must do. This is the backlog. The backlog can be groomed by the manager / sales / analyst / customer rep or everyone together. Each team has a ordered backlog, and each team member can pick work from that list.

Step 4: Sprints. You have a backlog, you have a team working on it. Now, give the team a chance to "demo" their work. Let's say they demo it every two weeks. They demo it to the customer and any other relevant stakeholder. This helps in getting regular feedback for the work done and course correction if required, it also is a great motivator for the team to perform. This iteration of work done and demoed is a sprint.

After the demo, the team sits together and says "oh okay, this is what we did. this is what we did wrong. this is what was cool. these are some action points for us to keep in mind for the future...". This is the "retrospective" meeting in scrum terminology.

---

Do you really need a "manager" or "delivery head". Not really, but you do need somebody communicating closely with the customer. Ideally there's a dedicated point-of-contact representing the customer and the team has direct and continuous access to him.

---

The leadership doesn't interfere with how the team works. But routinely checks with the client to assess their sentiment. Are they happy how its going? Usually they'll be happy but want more.

The leadership also routinely checks with each team. Are they happy? Is the customer forcing them to use archaic tools? Are there any impediments that weren't resolved within the team during the retrospective.

The leadership is generally hands-off and can focus on leads development, pre-sales and other business'y stuff.

---

Disclaimer: I am obviously not responsible for your interpretation of my message and its subsequent consequences. However I am available for consulting, my profile has contact info. : )


And that's three books on Agile practise in eight paragraphs.

You just ruined the consultancy market for three states :-)




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

Search: