Creating a career path

Your engineering team grows and grows. You hire a lot of engineers, the salary you give them is a mix out of what the candidates asked for and your gut feeling. From time to time you increase salaries to equal out the increase in cost of living and sometimes you have to promote someone to a management position and you give her a bigger raise, because it is a bigger responsibility. So all is good, right?

Well, it might be, but chances are, there are problems. See if any of the following points apply to your team:

  • In 1on1s you often hear the question: ‘Do I have to become a manager to get more money?’ This indicates that people feel there is no clear path for them to advance as an individual contributor.
  • Engineers are leaving your company to get a substantial salary raise. This is the big danger when there are no clear definitions of how engineers who improved a lot, can also make more money.
  • A lot of engineers tell you that you pay below market, but you don’t really know if that is actually true. You can compare your salaries to other companies, but this is usually done by comparing engineers on a certain level with each other.
  • Engineers are looking for an achievement and that is not necessarily only a salary increase, but they are looking for something they can put on their CV (like Senior Engineer).
  • Job titles go crazy and people ask “What do I need to do to get to the next level?”. This also indicates a lack of criteria what job title is appropriate for which level.


So if any of these points apply in your organisation you might want to think about creating a career path for engineers. Typically such a career path consists out of different steps an engineer can go through.

In the following I will present a model for a career path I introduced at different companies – plus some discussion about certain decisions you need to make when creating this.

From the beginning it was very clear that we wanted a model which offers engineers to advance either on a management path or an individual contributor (IC) path. Both paths should be equally valued and paid.

(In a former company you could only get to a certain job grade – which included a company car –  by becoming a manager. I saw quite a few very talented engineers with a company car, but without a job who was right for them.)

Taking that as one of prerequisites we looked at the Dreyfus model of skill acquisition ( which has the following five roles:

Level Name
1 Entry
2 Advanced
3 Proficient
4 Versatile
5 Expert

For each level we chose Technical Skills, Independence, Maturity, Business Perspective as the core criteria (note that technical skills is only one out of four criteria). For the management track we additionally chose management skills and we decided that the ladder should begin on the engineering path only.

(Green indicates the technical path, grey blue the management path)


Technical Skills:

The actual technical skills ranging from mastering the CS basics to successfully creating complex systems to being regarded a leader in the company or even in the industry.


Indicates how independent an engineer is on the lower levels and then if she can be trusted with leading other engineers.

Maturity: This is maybe the most important criteria. To cite John Allspaw ( here: ‘Being able to write a Bloom Filter in Erlang, or write multi-threaded C in your sleep is insufficient. None of that matters if no one wants to work with you.’. There should be a goal in every engineer’s career and that is ‘to be the engineer everybody wants to work with’.

Business Perspective:

How engineers build a constructive a relationship with other departments and looking at providing value for the business.

Management Skills:

As the management path starts on level 3, the different stages of a manager begin with leading a team, then leading other managers and in the end to lead a whole department.


Level Technical Skills Maturity Independence Business Perspective Mgmt Skills
Entry Good foundations in CS, patterns, BDD, TDD Accepts and adapts to criticism Work results need review n/a n/a
Advanced Better than Entry skills wise, so that she can work independently on tasks/problems Seeks out constructive criticism of their design. understand the non- technical area’s of how they are perceived Can work independently Builds relations with stakeholders outside the technology team n/a
Proficient Reasoning about system behaviour, weighs design decisions against stakeholder’s interest, makes reasonable compromises Provides and accepts criticism with proficiency, upgrades contributions of others, generosity of spirit Can be trusted with oversight of other’s work Has a solid understanding of business needs and other functional areas of company Can manage people
Versatile Able to project deadlines, make estimates, manage outcomes and communicate efficiently One of the engineers everybody wants to work with. Willing to do whatever is necessary, including trivial and non-sexy work Very independent AND/OR able to manage teams Takes ownership of everything (no CYA), Functional leadership, represents team professionally and consistently Can manage and mentor other manager
Expert Hard to grasp properties, commonly subsumed under the term seniority, has really good overview of the complete tech stack, could be considered a leader industry wide Generally relaxed attitude, knowing that knowing one that does mean knowing everything, willing to make himself unpopular at times (which is based on an intuition on long term consequences of decisions, but can that be backed by formal argumentation).Takes into account non technical aspects of engineering (humans, costs…) Starts and leads engineering wides initiatives Leader of company, not just function Manages a whole department


Some things you need to consider/discuss when designing this:

  • Are there job titles (is the job level visible for everyone) or is this just visible for the engineer? There are several pros and cons for both approaches, the most convincing for not making these levels visible at least in the beginning is that you can easily change from not visible to visible, but the other way around is pretty much impossible. So if you don’t have really good arguments for making them visible right away you should start with hidden job levels.
  • Do you attach salary ranges attached to levels? So for example the yearly salary of the Entry level is between X and Y $/year. It is usually wise to let salaries overlap – especially when levels are visible for everybody.


How to introduce it?

As you probably don’t have these levels from the beginning you need to slot a lot of existing engineers into the career path. This is something you need to do very carefully. First try it out by choosing a few engineers – I usually like to take one or more from each of the following groups:

  • You are certain that she will be fine with her slot
  • You are certain that she won’t be fine with her slot
  • You are not sure

and explain to them that you think it is time to introduce a career path and that you chose them to try it out because you value their feedback. Stress in every communication when slotting people that in doubt you always chose a lower level as promoting someone later is easy and the current salary is not affected by the slot anyway. If these discussions go as expected you can continue the roll out to the rest of the organisation.

What happens next?

In a normal organisation you will have a typical distribution of people in the job levels. There will be few in level 1 and 4, the majority in level 2 and 3 and very, very few in level 5. This might cause problems as soon as the organisation grows as it is very hard to get from level 3 to 4 and engineers might feel stuck. One potential solution is to split level 2 and 3 into two levels each.

The most important thing here is to constantly adapt this system to your organisation.

Have fun!

There are lies, damned lies and roadmaps

(title adapted from @StartupLJackson, but then I discovered that this phrase is actually much older:,_damned_lies,_and_statistics) 


Does this sound familiar?

The management team sits together and puts everything they can think of on the roadmap for the next quarter. The employees look at it, think ‘This is impossible!’ and after the quarter 15-20% of the roadmap items are actually done. This leaves a bitter feeling in the product teams (“We know it is not realistic, but we haven’t achieved our goals”) and destroys trust in the company’s plans and execution. The management team actually put a lot of effort into it (maybe even a two day ‘roadmap workshop’), which feels like waste.

Why does this happen?

The 5 sins of building a roadmap

  • Nobody looks at actual capacity and everybody assumes that the teams don’t have to spend time on maintenance work, bug fixes and other emergencies.
  • Putting things on a roadmap might be the only way to get items from teams outside of product done. A common example here is marketing, which often doesn’t have a dedicated team and so sometimes puts things like ‘fix the email system’ on the roadmap.
  • The roadmap is done purely top down with very little or no input from the teams. This way roadmaps are not aligned with actual team structure (which is not always bad) and the roadmap is more used to impress board or other stakeholders.
  • Put dates to everything – predicting actual dates a few quarters in advance is close to impossible and missing dates is never fun. So defines release dates as late as possible.
  • Some people confuse a roadmap with a comprehensive list of everything which will be released (‘fix the font on the careers page to 12px’). Please see below for a definition what needs to be on a roadmap and what not.

But first let’s talk about what in my view a roadmap actually is – in this blog post we are focusing on product roadmaps. This term is used very differently in companies:

A product roadmap is a tool that provides a strategic guidance to team members, business partners and customers. Please pay attention to the word “strategic” here – a roadmap should provide clarity about the strategic direction of a company in the next time (a few quarters)  – not about tactical things.

 A roadmap is not:

  • A list of detailed release dates of all planned features
  • A replacement for product backlogs (or whatever your teams use for the concrete tasks of the teams)
  • A place where the product leads try to impress other parts of the company with all the crazy stuff they hope they will deliver (but won’t)

But what is a product backlog now?

From Wikipedia: “The product backlog comprises an ordered list of requirements that a scrum team maintains for a product. It consists of features, bug fixes, non-functional requirements, etc.”

So a roadmap heavily influences a backlog, but is only part of it. A bug fix is only part of a backlog, never of a roadmap. Constant iteration on features (making a feature better and better based on user feedback and metrics) is also only part of the backlog.

Before talking about how a roadmap should look like, let’s get into more detail why a roadmap makes sense. We mentioned strategic guidance above, let’s talk about that in more detail:

  • It makes the strategic direction visible to other departments (including board).
  • To quote Eisenhower: ‘Plans are useless but planning is indispensable’. The actual process of building a roadmap can create a lot of understanding of what the company actually has to do.
  • If done right it gives the single teams the understanding how they contribute to the overall success of the company. If a top KPI of a company is Engagement and a team works on a engagement roadmap feature, it should be clear to the team how they contribute to the company’s success.

 How should a roadmap look like?

Typically a roadmap contains release names and approximate delivery dates if the confidence in those dates is high enough. Releases should be ordered by priority:

EXAMPLE ROADMAP (assuming it is created end of the year)


January: Release completely revamped Android app

February: Release new website design in time for big web conference on the 17th

Q2, Q3, Q4: (ordered by priority – dates get fixed as soon as confidence is high enough)

Internationalization (preparation for entering new markets)

Revamped Statistics (big new feature to excite customers)

Move to new Data Centers (has big internal impact)

Enter Brazil (first market entered outside the US)


If you want to create a roadmap which is ambitious, but realistic and gives the company strategic guidance you should follow this basic guidelines:

To make it ambitious but realistic – do retrospectives every quarter and adjust if necessary ,if you don’t have an understanding of your capacity.  Include the actual teams in the roadmap process wherever possible and remember: ‘It is better to underpromise and overachieve than to overpromise and underachieve’

For strategic guidance only put items on the roadmap which have strategic value, if there is a need to put other items on it – try to fix it in a different way than polluting the roadmap. To repeat the marketing example from above you could build dedicated engineering capacity for marketing.


Peer Feedback

Introducing Peer Feedback/Review 

Does this sound familiar? You take over an engineering team in a fast growing startup and before you even know what is happening 30 people report to you. You try to do regular 1on1s (even though the scheduling is very tough) and then in those meetings you get asked this very important question:

 ‘How am I doing?’

So people are asking for feedback (please see link). For this there are three possible answers and only one of them is good:

  1. ‘No Idea’: obviously not the ideal answer, but at least it is honest
  2. ‘I heard…’ probably the worst answer. You try to give some feedback, but you don’t really have anything to share. So you start spreading rumors (Feedback should always be direct)
  3. You actually have worked with the person and can give good feedback. In my experience this happens not that often and this question (‘How am I doing?’) can and should be answered by all peers (meaning colleagues that person has worked with)

So what can you as the manager of that team do? Well obviously having 30 direct reports is something you should change, but building engineering management takes quite some time. One way to give engineers feedback is to introduce Peer Feedback and that also makes sense as soon as you have built your engineering management structure. 

In general the manager is just not the only person which should give feedback. Look at one engineer in a team – she is pairing with other engineers, working closely with product management and design and sometimes she even speaks with her manager. So to get feedback for her the most reasonable way is to get it from the people she works with.

Peer Feedback

Let’s start with defining the main goal first as it can severely influence the design of the feedback process :

Is it about people receiving feedback about their work? Or is it about managers having more feedback to make decisions about Salary/Promotion? If it is the first, you should call it peer feedback otherwise peer review. This mostly determines if the feedback has any influence on salary. (If managers see it, it certainly will have). There are companies where salaries are determined by peer feedback and it often leads to non critical feedback as the reviewers don’t want to spoil a salary increase.

So, after defining your main goal there are still some design decisions to make :

Is the feedback anonymous or not?

So, can the reviewee see the name of the reviewer attached to the concrete feedback or does she only see the compiled feedback? Both approaches have pro’s and con’s.

 Pro anonymous:

  • Reviewers might be more open to give critical feedback as their name is not attached to it.

Con anonymous: 

  • Feedback is sometimes short or useless. Some people feel more responsible when their name is attached to it.
  • Starting a discussion based on the written feedback is very difficult (if not impossible)  as the reviewee does not know who gave a specific feedback. If you view written feedback as the start of a conversation, anonymous feedback is not the right choice.

Structure of feedback form

So, what kind of questions are being asked? Do you keep the form simple with just a few text questions? Do you use questions where people have to answer on scales? How much time should it take to fill out a review? In general it is advisable to start with a form that can be filled out easily and quickly. 

Who determines the feedback group?

Basically the question is: Does the manager determine the feedback group or the reviewee? The best experiences were made with the reviewee determining the feedback group and the manager checking it to see if it makes sense.

 Visibility of results

Who sees the feedback? Is it only the reviewee? If the goal is only feedback to the employee, it might make a lot of sense to give the feedback directly to him. In other cases it might be reasonable that the manager goes with the reviewee through the feedback.


 In one of my former jobs we – after making the decision to introduce peer feedback – assembled a group of people, consisting of employees working at HR and engineering (individual contributors and manager) to come up with a proposal. It took us three sessions to come up with the following outcome: 

  • The feedback was not anonymous, we wanted to have the opportunity to have a conversation about the written feedback
  • The feedback form consisted  of 5 text fields:
    • Technical Skills: What’s awesome, what needs to be improved
    • Cultural: What’s awesome, What needs to be improved
    • One text field for a message which only the manager can see. We put that field in so that feedback like ‘I think xxx should not be in this team’ could  be given.
  • The reviewers were chosen by the reviewee with the following restrictions:
    • The manager had to be part of it
    • if applicable the product manager had to be part of it
    • At least one team member had to be part of it

We introduced it by (everybody knew it was coming because we formed the workgroup by asking everybody about joining) doing a few test round. We asked people to volunteer and we did three rounds of peer feedback with one reviewee each round. After each we sat together and discussed the results (and changed a few things).

We also had a few problems, the most common ones were: 

  • Some people were really hesitant to give critical feedback.
  • A few people were overloaded by feedback requests.
  • Some feedback was not meaningful (‘everything ok’).

But in general everybody was very happy about it – that the team was helping designing it made them accept this approach and quite a few helpful discussions resulted from it.

When not to introduce peer feedback

There are also situations where you should be very careful about introducing peer feedback at all. For example if you manage a team with trust issues, then introducing peer feedback would probably not make sense.


Introducing peer feedback helps a lot in situations where a manager has too many reports to give feedback directly. But also if there are only 5-7 reports peer feedback makes a lot of sense as the manager is not the only person who can give valuable feedback.


Pragmatic advice on 1on1s

You read that 1on1s are a very important meeting for managers, so you schedule them from time to time. Unfortunately there are sometimes big gaps between meetings as you are travelling or busy and you forget to schedule those meetings. When having them you do have a nice talk with your report, where she gives you a long status update,  but after a while it feels like no side is getting anything out of these meetings. Then your report quits and mentions that she could not see any development for her role and therefore looked for a new job.


So maybe not all of that might sound familiar to you but I bet every manager has at least experienced some of these things. 1on1s are actually not that hard if you follow some of the easy rules outlined below:

  • Make it a repeating calendar entry

Why should anybody schedule each meeting separately, when it should happen every two weeks? And still I see a lot of managers who do that. Choose a day/time and frequency (more to a suggested frequency below) and make it a repeating meeting in the calendar – so you only have to change it if someone travels or is sick.


  • Day to day vs. long term

So in the example above the employee quits because she doesn’t see any development for her. Why is that? Most likely the manager and her never talked about it. This is a big risk in 1on1s that they tend to be very focused on day to day issues and seldomly about longer term topics like career development. This can be very easily avoided by setting up two different meetings. In my experience setting up a meeting with the title ‘AG/NF 1on1 day to day’ every two weeks and another one ‘AG/NF 1on1 long term’ works best. You can obviously change the scheduling as you want, but separating day to day and long term helps a lot. (AG and NF are initials of the manager and report).

This schedule means that you have three 1on1s a month with your report, I’d consider this the minimum.


  • Have a document for it

Do you know this: ‘wow, I need to talk to my report X about this topic’ – and then you forget it until the next 1on1 happens?

The solution is easy: Create a document where you (and your report) collect all topics which should be discussed in the next 1on1. Here I personally prefer Google Docs, but other documents are also fine. As a nice side-effect this document is really great if someone switches managers and the new managers can see the whole history of 1on1 topics.




Needed Reqs for Q3

RfQ for next CDN contract


Review Q2 targets (done)

Sync about conference attendence (agreed on Velocity in NY)



  • Standard questions

Now you have regularly scheduled meetings with a document and a good separation between long term and day to day topics, but what are you now actually talking about? There are a lot of standard questions to be found on the web, here are some I constantly use:


– How are you? (sounds funny, but it is always a good start)

– How can I help you the best?

– What are your biggest impediments to do a better job?

– Are there any performance issues in your team?

– Do you feel confident hitting the team goals?

– How is hiring going?

– Who in the company is doing an exceptionally good job? (I always prefer this way of asking because the positive spin makes people answer more honestly)

– Where do you want to be in this organisation in 6 months/2 years?

I hope that helps for starters. There is obviously way more to it then the few things I mentioned above, but by following those points you can avoid the most common pitfalls.

How to make a hiring decision

Hiring is one of the most (if not THE most) important things that a manager does to build a team and an organization. At the end of a hiring process a decision has to be made and how that decision is being made can make or break the whole process. There are several well-known hiring-decision processes, which each have pros and cons. An effective hiring-decision process satisfies the following objectives:

  • Ensure candidate is a cultural fit.
  • Ensure candidate’s skill set is a fit.
  • Avoid hiring out of desperation.
  • Make sure that everyone involved in the hiring process is heard.
  • Gather thorough feedback to create a comprehensive view of each candidate.

I will describe some common approaches I’ve seen in previous companies (if you have more please describe them in the comments!):

Fully-accountable hiring manager

Regardless of how many interviews a candidate has, the hiring manager makes the final hiring decision; the hiring manager is fully accountable for the decision. Although the hiring manager takes interviewers’ feedback into consideration, he or she can veto a majority vote.


  • The accountability for the hiring decision is clear.
  • If the interviewers inconsistently vet a candidate’s qualifications, the hiring manager can eliminate feedback that is based on irrelevant hiring criteria and perform the hire.
  • When many people are involved in the interviewing process, the hiring manager can act as a tie-breaker to make a quick decision.


  • If the needs of the manager and the organization are not aligned, issues can arise that negatively affect the organization.
  • It is possible that the hiring manager makes a decision out of desperation, which is more probable for one person than it is for a group.
  • If the hiring manager and organization are not aligned, he or she might hire a candidate for the incorrect reasons. This might occur, for example, when the manager is a new hire.

High-ranking hiring manager

A high-ranking manager hires and assigns a candidate a role that that hiring manager deems appropriate at the time. The new employee then reports to a manager in a different area of the company than to the manager who performed the hire. This is what in engineering would be called “cowboy coding”, and unfortunately this hiring strategy still exists in many companies.


  • The process can be really fast.


  • The hiring manager does not understand the actual needs, skill pool, and culture of the team for which they are hiring.
  • The actual manager faces unnecessary surprises that can negatively affect resource planning and cause tension within the team.

Interviewers reach agreement

The interviewers, which include hiring managers and technical experts, reach an agreement. Agreement means that the interviewers, either unanimously or by majority, agree to the hiring decision. For an agreement that is based on majority, the number of interviewers must be odd.


  • The hiring decision is democratic.
  • There is common agreement. For example, sometimes an individual is not convinced that someone is a good fit, but will trust their coworkers.
  • There are no surprises because everyone gets to meet the candidate before he or she joins the team.
  • This strategy allows the team to self-manage. By following this approach the team better understands its own needs, as opposed to having someone impose things upon them.


  • If one or more interviewers are not sure about what kind of talent the organization is looking for, the feedback criteria is inconsistent.
  • It can be difficult to come to an agreement if a lot of interviews take place.
  • When compared to other strategies, there is a higher probability that politics and personal relationships will adversely affect a decision to hire or to not hire a candidate.

Hiring committee

An independent committee of Googlers review[s] feedback from all of the interviewers. This committee is responsible for ensuring our hiring process is fair and that we’re holding true to our ‘good for Google’ standards as we grow.” What is the difference between this strategy and the Interviewers reach agreement by majority strategy? A hiring committee does not interview the candidate, and relies on written feedback.

Why is there no hiring manager for this role? Don Dodge best explains, “Hiring decisions are made by hiring committees. This means that no single hiring manager can make a potentially bad decision by themselves. This doesn’t guarantee 100% success, but it does reduce bad decisions. There must be consensus that the candidate is a great hire. Doesn’t this slow down the process? Not really, in fact the process insures that candidate status is reviewed by the committee every week. There is no opportunity for the hiring decision to get delayed by personal deadlines for other work. The consensus approach avoids ‘blind spots’ or biases by an individual hiring manager, and results in better hiring decisions. Candidates are compared across several groups to make sure the acceptance criteria remain high.

Google employee Piaw Na writes anecdotally, “…when the committee found feedback on hiring to be ambiguous, it would assign another interview to an engineer well-known to be decisive … many people dislike rejecting people, and occasionally, someone would write feedback that wasn’t really informative enough.”


  • The chance of a single individual making a poor hiring decision is eliminated or significantly reduced.
  • The acceptance criteria for hiring a candidate remains across several groups.


  •  The member of the hiring committee rely only on written feedback which might be incomplete or misleading
  • The candidate’s future team is not in control of the hiring process, and cannot ensure that there is a cultural fit between itself and the candidate.

Bar raisers

Amazon’s CEO, Jeff(rey) Bezos, uses “Bar Raisers” in the hiring process. “The bar raisers had generally been at Amazon long enough to know what the corporate values and culture [were] like, and generally were the best employees in terms of productivity, inventiveness, and technical acumen. And they were authorized to spend up to 25% of their time on recruiting. … Bezos felt that making good hiring decisions was the most important thing the company needed to do successfully. Every employee hired was required to interview with a bar raiser from another team. And hiring decisions had to be unanimous.”


  • Someone who knows the requirements of the organization is always part of the hiring decision.


  • [There are no known disadvantages to this approach.]

Fully-accountable HR representative

In some companies, an HR representative makes the final decision about which engineering candidate to hire. Similar to the Fully-accountable hiring manager, the HR representative is fully accountable for the decision.


  • The accountability for the hiring decision is clear.


  • The HR representative alone does not have enough technical knowledge to make an informed decision that is based on a candidate’s technical skills.
  • If the HR representative is not sure what kind of talent the organization is looking for, he or she might hire a candidate for incorrect reasons.
  • It is unclear if the HR representative is hiring for himself or herself, or for the organization.


So there are obviously a lot of different approaches and there is not a clear cut winner for every organisation. There is pretty convincing data that having more people involved in the hiring process results in better hires, but I haven’t seen any data that “interviewers reach agreement” is better or worse than “hiring committee”.

Where I currently work (SoundCloud) we decided for the following approach:

One of the key was to find a common approach for engineering and other departments – the key difference here is that engineering often does not have a clear cut hiring manager, while other departments tends to have one.

We agreed on the following core concepts (which is basically the “interviewers reach agreement” approach combined with the bar raiser):

  • Interviewers are either decision makers or advisors. The decision makers’ votes have to be unanimous, and any single decision maker can veto a hire. Advisors are heard but cannot block a hiring.
  • The bar raiser concept is applied as a bar keeper. The bar keeper is always a decision maker, and is usually a senior employee from a group that is not directly involved in hiring the candidate.

In engineering usually everybody is a decision maker. Exceptions are employees doing their first interviews and positions where so many interviewers are involved that consensus is close to impossible.

So in general it makes a lot of sense to really think about how you make a hiring decision as this severely impacts an organisation. And again this wise principle applies here: As a manager you should not make every hiring decision but rather install a process which ensures that good decisions are being made.


Scaling a start-up

Feature or component teams?

The first team in a startup is a feature team by default. But as the
company grows and you hire more developers, a common question pops up: How
do you structure your engineering department when you have more than one
team? Two common approaches are teams per component/service/layer or
feature teams. This article describes the pros and cons of each approach
based on experience.

So you have a startup. Let’s assume for the sake of simplicity it is a
consumer facing website done in Ruby on Rails with an underlying database
(but this article applies to other kind of startups too). You have around
10-15 employees, of which 6-10 are developers. These developers are one
team, some of them concentrate on front-end work, some on the back-end,
the mysql database is maintained by a handful of the developers. The team
feels like it has reached the natural size limit and is considering
splitting into smaller teams.

Before discussing team structure let’s first talk about some important
goals while scaling up the company.These goals should determine what you

* Developers should have as much knowledge of the system as possible,
so that there is no single point of failure and technical decisions are
made with an understanding of the overall system.
* There should be common approaches to most technologies like CSS and
for some technologies, like databases, specialists are needed.
* Communication overhead should be avoided where possible as well as
handovers between teams.

Overall there should as much common knowledge as possible but specialists
where needed. Let’s first discuss the terms “Feature Team” and “Component Team”,
especially in a startup context.
The usual definition of a Feature Team is:

Feature teams are supposed to be cross-functional groups that focus the
software development process in valuable-chunks of work, which normally
cross the whole system (vertical slices of the system).[1]

While this sounds good you usually reach pretty fast the team size limit
when trying to compose teams which can touch every part of the system. At
SoundCloud we currently have 35 engineers working on topics like Android,
iOS, Search, Anti Spam, MySQL, Operations, Web Front-end, Back-end and so
on. So you can see very easily that if you define seven as an ideal team
size, we have difficulties forming teams which can touch every part of the
system. A lot of consultants say that engineers should be able to work on
any part of the system, but in reality and especially if you operate under
scale, where for example every single SQL query can impact the site, this
just does not work.

Component Teams are usually defined as horizontal slices of a system, so
for example front-end, presentation layer, business logic, database and
operations. But I haven’t seen a startup which organizes it’s teams
exactly that way. This is usually a team structure big companies choose.
But what I’ve seen at a lot of startups is the separation between front-
end, backend and operations. There are lot of obvious disadvantages
associated with component teams:

* Features often touch several teams, this leads to costly handovers
* Teams often act as silos and lose sight of the coherency and goals of the product

But especially in large organisations component teams also have some
advantages, like having dedicated teams for components – like databases –
under scale. (please look at [3] for details)
So, we now have two approaches which on the surface both are not
applicable for startups either at all or from a certain size on.
Reading the post from Vasco Duarte ([4]) clarifies the situation in a very
good way. Feature teams are not necessarily defined by their structure,
but the most important thing is that a feature team can deliver value to
the customer without dependencies on other teams. The reason for that is
to reduce handover between teams which usually produces what “waste” is in
terms of lean. Citing Vasco:

A feature team is not defined by it’s structure (being cross-functional),
it’s defined by it’s output! (delivering shippable pieces of the

A common anti pattern for that is (similar to the one mentioned in the
article) is that design is not integrated into front-end teams. This often
causes blocked user stories (waste) when design specs are either unclear
or during implementation a necessary change in design has been discovered.
In reality there is no such thing like having absolutely no dependencies
on other teams. So we defined teams, which can work on the vast majority
(at least 90%) of the stories in their backlog without needing other
How those teams are formed changes over time. We at SoundCloud did not
always have a stable API. So in the beginning front-end and back-end
developers were one team until we were able to extract a well defined API,
which offered the necessary functionality for all front-end clients
(mobile and web). At that point we separated the joint web team as the
front-end teams were now enabled to work on the majority of features
without involvement of the back-end.
Looking back at the start of the article where we defined that we want to
have developers as much overall knowledge of the system as possible it
seems like the chosen setup at SoundCloud violates that. To achieve a
compromise, we encourage developers to rotate through teams. Some
developers want to stay in their comfort zone (these are often the
specialists mentioned above), some are interested in all parts of the
system. As long as half of the developers in a team are aware of what
other teams are doing, that team will be fine.

Combine both approaches

The question is not so much which formal definition of team to follow. The
importance is for teams to deliver the majority of stories in their
backlog without depending on other teams. And team composition ought to
change over time as the overall software stack matures.
Analyze your teams if they can deliver value without depending on other
teams (for at least 90% of the features). Do this regularly and team
composition changes over time just as architecture does!

Inspired by:

[1] Scaling Lean and Agile Development, Larman, Vodde: Feature team
definition on page 153
agile-at-scale-feature-teams-versus-component-teams-part-1/ <about:blank>

Scrum – Quo Vadis?

Ten years after the Agile Manifesto, Scrum is a mainstream software development approach. However, where has Scrum really proven to be successful? Many implementations are process- driven and neglect the core values of the Agile Manifesto and good software engineering by focusing purely on roles and meetings. Some organizations take the opposite approach and focus purely on XP practices. This article will take a look at what has proven to be successful and will show which approach is the most promising in which environment. Special focus is given on what can be considered as reasonable steps for moving from the current status of software development to something better (as the main intention should be to improve, not necessarily to simply introduce Scrum).
How often have we heard statements like “We do a daily standup and a sprint planning meeting, therefore we are doing Scrum and are Agile”? It should be obvious that this statement is far from true – but how could those misunderstandings happen? One of the core reasons is the way Scrum is (mis)understood and taught by Scrum consultants (who may have little experience in software development).
Developing software is not just a process; it is also about soft- ware engineering practices. Organizations need to invest in both: processes and engineering practices. Anecdotally, it seems that after the introduction of Scrum, some organizations appear to have a better process in place, but their software and its delivery have not improved.
As Scrum is introduced, a lot of money is usually made with certification and training, consultants are present during the first sprints, Product Owner, Scrum Master and team learn what to do and who is allowed to do what. However, will this really produce better software? The answer to this question obviously depends on how the organization developed software before Scrum was introduced. One thing is clear, however: you may be better, but you are far from optimal.Let’s first look at what should improve through the introduction of Scrum:
  • It creates visibility, to the Scrum team itself (where are we exactly, what are our next tasks) and to all stakeholders
  • The existence of a prioritized and estimated backlog is very valuable
  • Scrum aims for shippable software each sprint. This is a major step forward for typical organizations, where releases are done a few times a year and each release is very painful
  • Rightly implemented, Scrum removes the typical barriers between Product Management, R&D and QA

So a lot of good things! Don’t get me wrong, this article is not supposed to bash Scrum. It should rather show what needs to be done after or during the introduction of it. So what is missing, or what are common anti-patterns seen in Scrum implementations?

  • Often “Mini Waterfalls” can be observed: the first days of a sprint the team works on the specification, then they imple- ment and during the last days of the Sprint, there is hectic QA activity prior to the Sprint Review meeting.
  • In a lot of Scrum implementations the only success criteria is that the Scrum roles exist and all the meetings take place. This has obviously nothing to do with Agile software develop- ment.
  • Neither software engineering practices (like TDD or pair pro- gramming) have improved nor the delivery process of the software.
  • As Scrum does not include Operations staff in its team, this barrier still exists.

Before discussing this further, let’s have a closer look at the Scrum roles.

The Scrum Roles

There are three major roles in Scrum (descriptions taken from the Scrum Alliance web page):

The Product Owner: Decides what will be built and in which order. Also he accepts or rejects work results.
The Scrum Master: Is a facilitative team leader who ensures that the team adheres to its chosen process and removes blocking issues.
The Team: Well, they are the ones who deliver the actual work.
So, you need a team that does the actual work, you need someone who actually determines what is being built, but do you really need a Scrum Master? Nearly everybody would answer “yes, of course you need one!”. Let’s have a closer look why the Scrum Master is actually there: To compensate for shortcomings of the overall process/team. Scrum should in theory work without the Scrum Master assuming that the team is really self-organizing. That means they don’t need to be dragged to the meetings, and the team (everybody) knows how to remove impediments. So, the evolution of an Agile team should lead to either no Scrum Master or to one with a very reduced role.

Scrum and Continuous Delivery

In Scrum the result of a sprint is “potentially shippable software”. This definition leaves a lot of room for interpretation; let’s just assume that for consumer facing Internet services this means a deployment to production. What happens if a team needs or wants to deploy more often? Doing a big Sprint review meeting at the end of a Sprint is not enough. Essentially, the Product Owner needs to constantly accept functionality, and the need for one big review meeting is gone. And by the way: The need for a retrospective is not gone, and this meeting should be held each Sprint/ Iteration.
Outlook for Scrum?

In my opinion it is time for two things:

1.    There has to be something like a “Scrum 2.0”, which should address the current shortcomings, especially that Operations people are not part of the Scrum teams and that Scrum is introduced without software engineering best practices.
2.    Companies should be clear that for a lot of them (not all!) the journey does not stop with introducing Scrum. Good soft- ware engineering practices (XP), automation and the ability to deploy to production more often are key.
In my view combining Kanban (limiting work in progress, deploy every feature which is done) and Scrum (Retrospective) elements together with XP practices is the way forward for having a strong software development unit.

Inspired by:

Striking a Balance: Let Scrum Die
Scrum 3 Stages of Evolution – Explored es-of-evolution-explored/
Martin Fowler on Avoiding Common Scrum Pitfalls
Scrum Certification Test

and Martin Fowler’s keynote at OOP 2011