

Ask HN: How to keep a tight tech team in a consultancy? - Eclyps

Every article that I read about managing a development team is geared towards a single company developing a product, where all developers are working toward the same goal of delivering said product in the best way possible. There is some really great information out there, but I can’t seem to find anything that’s geared more toward consultancy-based organizations. Here are some big differences that I see:<p>* We are working on projects, not a product. A lot of what we do doesn’t come down to what the end-user wants, it comes down to what the client wants (and sometimes those wants are really, really strange).<p>* Our projects can be wildly different from one another (though we stick with a standard stack as much as we can).<p>* The entire team isn’t working on the same project at the same time. We currently have 6 developers, at any point we might have 1-3 on the same project. That means that we can have 2-4 unrelated projects going on at one time.<p>* Our timelines and budgets are relatively fixed, and need to be provided prior to development and adhered to.<p>Different projects have different requirements and allow for different levels of flexibility. Some projects it might make sense to go with TDD and weekly sprints. Other projects might have an extremely short shelf life and just need to get out the door, so spending time on code coverage and refactoring may not be something that makes a great deal of sense. We have our own values and processes that we use for every project of ours, but the constant changes in our client’s needs make it difficult to form a solid repeatable methodology.<p>Can anybody recommend some reading material that’s more focused on project-based work rather than product-based? Any personal advice about managing a team where members are often working on different projects from one another? Thanks.
======
oferzelig
Man, I have so much to say about this but it's not the right time and the
right place.

One quick reflection: unless it's a very very short project (say less than 2
weeks) no one knows the exact content of the project - not you and not the
client. It ALWAYS changes. Take that into account when determining price,
and/or when a change comes in, know how to flag it to your customer right away
and charge for it. Otherwise you end up doing tons of very small changes (each
one seems like would be unfair to charge the customer extra for) that
accumulate and you end up paying a lot more to your employees and lose money.

------
rsto
Maybe you could find something in Joel Spolsky's earlier blog posts
[http://joelonsoftware.com](http://joelonsoftware.com) ? Today, FogCreek
focuses on their products, but in the early days they set out to build a
developer-centric consultancy.

~~~
Eclyps
Great suggestion. I've read his classic posts, but I haven't gone beyond
those. I'll take a deeper look. Thanks.

------
rubiquity
Shit clients say:

\- "This project/change is easy"

\- "This project/change won't take very long"

\- "I know this isn't the rate you wanted, but we're totally gonna give you
more work at the rate you did want later on"

~~~
Eclyps
But honestly, I have none of these problems. If one of our clients tell us any
of the above, we explain to them why that's not the case, and if they continue
to press us, we show them the door.

We solved that problem early on - now we're just trying to figure out the best
way build cohesive dev team when we can't apply standards across the board for
all of our projects.

