
Years and lessons working at ThoughtWorks - rspivak
https://www.thekua.com/atwork/2016/04/12-years-12-lessons-working-at-thoughtworks/
======
henrik_w
I love reading "lessons learned" type posts.

The ones I like best here are:

#5 Architects make the best decisions when they code. Amen.

#10 Appreciate that everyone has different strengths - that's how a team
becomes more than its parts.

Here are my lessons learned from 25 years of SW development:
[http://henrikwarne.com/2015/04/16/lessons-learned-in-
softwar...](http://henrikwarne.com/2015/04/16/lessons-learned-in-software-
development/)

~~~
gav
> #5 Architects make the best decisions when they code.

It's not just a matter of coding, it's about the right kind of coding.

I like to have architects be pareto-programmers, that is they get to 80% of of
the solution so that they can hand off the rest to a less-experienced team
member. They can solve the hard part of the problem without getting stuck
making it productionized and provide an opportunity for mentoring.

There's two other code related tasks that are important: code reviews and
commit reviews. They give views at different "heights". We have fairly good
tooling around the former; I'd love a tool that gave me an email every morning
that had X number of random commits distributed over the total committers as
best as possible while showing me who hasn't committed for a while.

~~~
Swizec
As a team member, pareto programmers are the worst. They do all the fun
interesting work, then raise their hands and push the important work on the
team. They refusw to take ownership of their features, create a mess for you
to clean up because they certainly missed a detail or two, and just generally
suck to work with.

The worst is when they say "This is your code man. I'm just helping you out a
bit."

No. Finish the fucking feature so I can focus on my fucking feature without
having to tripple check all your damn work.

~~~
coredog64
I get your frustration, but I've also seen some pretty bad code where junior
developers were given too much freedom to do the "fun, interesting" work. When
concerns were raised during pull request reviews, the inevitable answer was
"not gonna change it -- approve it now because my sprint is in danger".

~~~
hibikir
You just hand them fun, interesting work that doesn't do too much damage to
the company when it fails. In practice, this means that your most senior
people end up doing work that is very interesting, yet very arcane.

I mean, anyone senior around here should know that it's precisely making
something production ready, as opposed to just 'work in theory', is one of the
hardest parts of software: Who hasn't seen some code that mostly works, but is
operationally unusable? Something that works with 1 server, but when you put
it in 20, it all blows up? It's not about the nice presentation, or the talk
where you explain how you turned MongoDB into a queue, but about making a
system that works almost all the time, but when it doesn't, it is not the end
of the world, and easily fixable.

The sad part is, the world is so full of powerpoint architects and projects
that don't provide any real value that many people have never seen a system
work right. And that's why we see tons of SV companies that are built around
tire fires: Nobody in charge of anything has ever seen a system that we
shouldn't be embarrassed of.

~~~
erichocean
> _but about making a system that works almost all the time, but when it doesn
> 't, it is not the end of the world, and easily fixable_

This is exactly where senior architects make all their money.

------
mangeletti
I worked with some ThoughtWorks consultants a few years ago, and I would say
the author here is probably a diamond in the rough. This was a very good read.

ThoughtWorks needs to read this and particularly heed point #9. The primary
goal of theirs during our month—or so—long consultation seemed to be to force
a team of 40+ developers down a rigid and dogmatic path of TDD. They also
advocated pair programming, but a lot of us (I'm extrapolating "a lot" from
the unanimity of the few I was close to and talked to about this) felt like
they were really just winging it; like they were apprentice developers barely
learning the concepts of TDD and pair programming at the same time they were
charging to purportedly teach us.

It was a frustrating and fruitless endeavor that taught our team basically one
thing; don't work with ThoughtWorks again.

~~~
davidrupp
Ex-ThoughtWorker here. Pat is indeed a respected voice in this space, even
amongst ThoughtWorkers, but he is not the only diamond. I learned pair
programming and TDD from many colleagues over three years and four major
projects. In all that time, there was exactly one individual whom I thought
was a waste of space. On the whole, ThoughtWorks' typical approach to agile
(note: lower-case 'a') development is firmly grounded in the pragmatics of
what used to be called Extreme Programming, not Scrum-type dogma.

I'm sorry you had a bad experience in your brief engagement with TW. I believe
it to be atypical, and I hope you'll have occasion to reconsider your -- not
un-dogmatic -- conclusion.

------
jph
ThoughtWorks hired me this month. The culture is _excellent_ and matches up
with these 12 lessons. I'd add a 13th lesson about combining individual
empowerment with teamwork.

If you're interested in working with ThoughtWorks, I'm happy to help and
connect you with the right contacts. Email
joelparkerhenderson@thoughtworks.com.

~~~
MrBuddyCasino
Are they still traveling a lot at TW? I don't want to live in a hotel for 4
days a week, so I declined when they approached me.

~~~
Garbage
Well, traveling really depends on project. But you can actually ask for non-
travel project.

I would recommend talking to the recruiter and let them know your preferences
before declining.

~~~
MrBuddyCasino
> you can actually ask for non-travel project

Interesting, thanks. At my current job they try to staff local as much as
possible, there is no formal hierarchy and we also have 20% time, so my
standards are high. Traveling too much would be a no go for me.

------
nvarsj
_Although not all pair programming environments are healthy, I do believe that
when it works well, teams tend to have better collaborative cultures. Many
developers prefer the anti-pattern of (long lived) branch-based development
because it defers feedback and sources of potential conflict._

Ugh, such a false dichotomy. Does anyone actually think
[http://nvie.com/posts/a-successful-git-branching-
model/](http://nvie.com/posts/a-successful-git-branching-model/) is a good
idea?

Instead, compare to any one of hundreds of successful examples on github, all
using feature branch based models.

Thoughtworks (and other consultancies that take the CD book to heart) would
have everyone pair programming and committing directly to master. This simply
doesn't scale beyond a small team. It also actively discourages collaboration
across teams, because there is no process in place to review external
contributions.

~~~
davidrupp
"[P]aired programming is about optimizing for the team" (source:
[http://goodrequirements.com/2013/pair-
programming/](http://goodrequirements.com/2013/pair-programming/)). Long-lived
feature branches optimize for the individual. A useful alternative is
described at
[http://paulhammant.com/blog/branch_by_abstraction.html](http://paulhammant.com/blog/branch_by_abstraction.html).

What is your definition of "small"? The projects I worked on at ThoughtWorks
for over three years numbered in the dozens of developers, all pairing, and
all committing directly to master.

------
dominotw
I worked at place where they had multiple vendors work on the same project,
client prbly din't want get locked in with one vendor.

Thoughtworks was one of the implementors and I was with another vendor.
Thoughtworks had 'agile coaches' on the team who would dictate process and
alienate anyone who wasn't from thoughtworks, only thoughtworks employees had
access to their 'mingle' project planner where they would do all the planning.
One of the main objectives of these 'agile coaches/architects' was to make
sure they lock down this big client for future projects by integrating
themselves deeply into clients processes and alienating everyone else. Their
commercial products like mingle are explicitly designed with this in mind.
Their 'take over' phase also involved binging in lots of young consultants who
would work really long hours, most of them on my project were fresh college
graduates from their bangalore/pune office bought overseas on L1 visas who
work 12-14 hr days.

Anyone who questions them would be labeled not 'agile' enough and by extension
a liability to the project. I left the project shortly because it was not my
battle to fight. Employees who worked there associated agile with consulting
company scam. It was disappointing to see agile methodology being coopted by
consulting companies for their own ulterior motives.

Thoughtworks was just another consulting company who uses 'agile' to out
maneuver their competitors. I always wondered why thoughtworks is considered
to be different from other companies in the class like accenture/ibm. I've
never used a product or opensource project made by Thoughtworks.

This was about 7-8 yrs ago so things might be different now, not sure if they
still doing their agile stickh.

~~~
simula67
Atleast two signatories if Agile Manifest has stated that the movement has
lost its way [1][2].

I think it never had a chance. With the old waterfall model, projcet managers
had some power : they could continuosly interrupt engineers and ask them to do
more and more since project went in one trajectory for years. They were
justified since the engineers had plenty of 'downtime'. Engineers had some
power, the project never changed direction and they could work out the design
and implement it carefully, managing technical risk.

When Agile came along, the idea was to change direction every two weeks, but
within the two weeks the team does not take on any distractions. I suspect
this delicate balance of power was created, not out of a sense of fairness,
but for efficiency. But when the people in power saw this they said : 'I will
take these parts of the methodology that are useful to me and ignore these
parts that are not useful'. Cue the 50 point stories, sprint abortions, mid-
sprint story additions etc. Question the reasoning and you are labelled anti-
agile. I suppose this was the only way it _could_ go.

[1] [http://blog.toolshed.com/2015/05/the-failure-of-
agile.html](http://blog.toolshed.com/2015/05/the-failure-of-agile.html)

[2] [https://pragdave.me/blog/2014/03/04/time-to-kill-
agile/](https://pragdave.me/blog/2014/03/04/time-to-kill-agile/)

~~~
parasubvert
" Engineers had some power, the project never changed direction and they could
work out the design and implement it carefully, managing technical risk."

I've seen the opposite more often: Many a waterfall had poor assumptions made
up front without a lot of technical risk management afterwards beyond
"helicopter parenting" from architects.

Most successful agile teams I run into, engineers hold most if not all of the
power to design and implement - the product owner wields ultimate power over
function and priority.

"When Agile came along, the idea was to change direction every two weeks, but
within the two weeks the team does not take on any distractions. "

That's Scrum's approach. Modern XP Shops I've tended to see adopt
iterationless approaches, where there is a retro and planning session every
week or so, but not really to recognize "iterations" per se. Features are
delivered when they're delivered, deployments and releases are automated so
they can happen whenever the product owner wants.

Biggest point of success, however is to eliminate project management as we
usually know it. There's a product owner, and a product manager and they are
usually an empowered customer paired with someone that knows how to build
"products", ie. A focus on learning and testing rather than the certainty
demanded of most projects. Project managers become at best glue players that
protect the team from organizational antibodies.

------
matt_wulfeck
> People won’t risk making mistakes if they feel they will do a bad job, lose
> respect from their colleagues or potentially hurt other people in that
> process.

This such an important and overlooked aspect to learning. Also one of the best
things I experienced when working for a startup. For whatever reason I found
the environment much more conducive to experimentation and failure. A working
POC could change the direction of a project. Most things didn't seem possible
anyway, so why not try?

Now at $BIGCO projects take a long time to start and are generally not full of
surprises. A change in direction would probably be perceived as a negative of
not thinking out your design more carefully.

------
zik
> Everyone can be a leader.

This seems like a naive point of view. In any real organisation people
naturally form hierarchies, even if they're implicit and unstated. It's just
human nature. Then if someone lower in the hierarchy starts to suddenly act
like a leader they'll have other people who are notionally higher than them in
the hierarchy stomp on them, quelling the usurper initiative in order to
maintain their own position in the social hierarchy.

This is such a deep part of human nature that people don't even know they're
doing it. It's well documented in psychology texts but for some reason people
deny it happens in their own workplace. Yet I've observed it happening in
every workplace I've ever been in.

~~~
draw_down
Yep, I agree. In pretty much every organization I've worked in, some engineers
are more equal than others.

If you're a golden child, you'll have praise heaped upon you for whatever you
do. If you're not one of them, you can take charge and go above & beyond if
you want... but probably no one will care. So at least for me, I really
question the value of doing those things nowadays. I just do my work, try hard
to do a good job, help out if I'm asked, and that's that.

The worst aspect of this dynamic is when you see one of the "more equal"
people doing something that's going to cause pain and trouble down the road,
but you know nobody is gonna listen. That's life as an engineer I guess.

------
mazatta
If the author is reading this, the social sharing buttons on that page are
very annoying. On my browser/resolution it covers up the first character of
every line it touches, which makes reading the article without resizing the
window nigh impossible.

------
otaviokzuk
I believe TW can be a great experience for many devs. But hey, don't trust
posts of their own people on the matter. This is a company where it's standard
practice for big wigs to post not only technical content, but also
"evangelising" stuff to attract other employees. Read glassdoor reviews from
current/ex employees and check how it feels for you.

Some people love it to the point of religious fervour, while other hate it as
if it murdered their mom savagely. So make sure it looks right for you before
applying for a job there.

------
AstroJetson

        Architects make the best decisions when they code
    
        In the Tech Lead courses I run, I advocate for Tech
        Leads to spend at least 30% of their time coding. 
        Spending time with the code helps build trust, respect
        and a current understanding of the system. Making 
        architectural decisions without regard for the  
        constraints of the current system are often bad decisions.
    

I really hate it when people don't know the difference between an architect
and a tech lead. I'm happy that you gave your tech lead a title bump if that's
what you want to do, but there is a difference. If you have your architects
coding you are wasting time and money. Hire another programmer and have your
architect do what they are supposed to.

~~~
umanwizard
Titles and job roles vary enough across the industry that I'm pretty sure
there isn't a canonical, obviously correct meaning to things like "architect".

~~~
AstroJetson
I agree that job descriptions can vary. The article says "Architects make the
best decisions when they code" and then goes on about having "tech leads"
code.

In a startup the CIO / CTO can be coders (they may be the other partner in a 2
person company). But in a company that is 12 years old, they should be at the
point that they have high level/high talent people doing those jobs.

So I would expect that they have a CEO that runs the company and a CIO that
runs IT and architects that do systems / application architecture. Not
spending a day and a half each week cranking out code.

~~~
nilliams
The argument I imagine (and that I agree with) is that if you aren't in touch
with the code you begin to lose touch (esp. in this fast-moving industry) and
you become an ivory-towered twit that your teammates can't relate to and begin
to resent.

I am a fairly experienced JS dev and I can't imagine retiring to a hands-off
architect role in that world, because there are so many tool choices and
options in terms of programming style (even languages that compile to JS), so
I feel like I need to be regularly writing 'app code' to know how to advise my
teammates well.

Saying 'though shalt write TypeScript and use these libraries, and these OOP
practices, and structure your app in this way' would feel fairly obnoxious if
I wasn't working with the team, with those technologies to write actual code
myself. If my teammates instead wanted to do functional programming in Elm,
and all I could offer was hypotheticals as to why that was a bad idea, I
really wouldn't expect my teammate's respect, and would expect them to be
quite-rightly put-out.

~~~
AstroJetson
There is a difference between the two. As an architect you would need to keep
up with what the different tool sets (compilers, transpilers, frameworks,
database interfaces, etc, ) and what's going on in those spaces. Understand
why your currently chosen toolset is working and where their roadmap is and
how well your company is on that roadmap.

Whats the new universe of tool in your space, is one of them going to help
you? Is it something you should pilot/plan for, keep an eye on or ignore?

You need to focus on that and figure that out. Having you work on tickets or
new features isn't the best use of your time. Working out how it all works
(and works well) together and where the holes are is your prime function.

Let's talk about the "Thou shalt". That's when you lead the education process.
Why AstroScript is the way, what it will do, how it will work, how it scales,
etc. You get some level of buyin and once that's done the team rocks and rolls
in that effort. You want to help out with the first set of features fine, but
once they get going let them go and get out of their way. You then look for
the next thing down the road.

Hey your team wants to do Elm? Is that in the plan, have all the little
nuances been looked at, does it scale, etc. etc. Yes, then go that way. No?
Then it's up to you to either close the gaps with Elm or put the ship back on
track. That's what architects do.

I understand people ending up as "white board architects". They suck, they
happen. You can be "hands on", be an advisory, be a resource, be involved with
the team. But you shouldn't be cutting daily code.

Lastly, I want to repeat that the original article is about a company that is
12 years old. Well past a few developers, a company that wants and should be
on a growth path. Scout around and look at some Y successes that are $100+
million companies. Track their architect(s) down and ask what they do. If they
are spending 30% of their time doing app-dev write back to me. Happy to treat
you to dinner anywhere in Philly.

~~~
solarengineer
I like what you've written.

What are your lessons learned on how Architects should keep up (and avoid
becoming whiteboard architects)?

My personal realization is that it is necessary to be hands on to understand
new technology rather than just reading up documentation and others' opinions
on such technology.

~~~
AstroJetson
Sorry about the delay, OBE in my day job.

One of the best things was posted by sheepmullet

    
    
        Don't give them any actual authority.
    

Actually this is good for any architect. The ability to achieve consensus
across all the groups gets you the buy-in that you need. It also ferrets out
the detractors that are going to spend the next decade throwing rocks at the
decision.

Next is go make friends with the operations people. Learn how operations works
and what they do, how they monitor, how they keep things running. While they
appear to be BOFH like, when they get the idea that you are listening to them,
they will help you out. Make sure someone from OPS is on your consensus team.
I had a white board architect (WBA) work for me and I made him get signature
approval from OPS on everything he proposed. After awhile he got it and became
less of a WBA.

Do lots of proof of concepts to see if what you are thinking about will work.
In the past I've had a cadre of co-ops / interns do the grunt work. They are
always excited about working with a new technology.

(If you are in the Philly Area, call Drexel University. You can get co-op
students year round in either 3 or 6 month increments. Pro tip: Don't hire
them until after they graduate. If you don't send the co-op back to the
University so the Uni can get the rest of their money, they will stop sending
you co-ops. )

The other advantage of co-ops is that you can afford to go down some dead
ends. It's a win-win, you use a less expensive resource to find out bad news,
the co-op gets to put "Worked on Astroscript at major company" on their
resume. It's very freeing because you can then take on someone from the
outside going "Hey lets do Elm", assign an co-op to do most of the grunt work
rather than burning your time up.

You can be as hands on as you want. I've always found that getting some new
tool installed is a huge mess. Need this library and that version of something
else, these scripts don't work, etc. So my co-ops do that. Once it's spun up
and running and their first mini-Proof Of Concept is working then I'll get
involved with a larger POC and get my hands dirty.

(An aside on the install mess. When we get ready to start the "Moving to
Astroscript" to the internal consensus cycle, I assign a co-op to package it.
They put together a clean setup process for both Operations and the Dev
Manager to sign off. Nothing kills a project faster than the people you want
approval from not being able to spin it up to look at it.)

It's mostly lots and lots of talking to people about what their pain points
are, what direction the business is going in, thinking about planned and
unplanned pivots, etc. Always be thinking about a Plan B.

My check list for new things (in order) * What business value does this bring
(ROI) * How does operations run this * What is the Disaster Recovery Plan *
What is the opportunity cost * What is the internal friction * What is the
external friction with our partners

Other things that may help:

Start a series of brown bag sessions (your call if the bags contain lunch or
beer) and present out to anyone what you are thinking about. ( Tip: Master the
ability to create a 50 minute long Powerpoint in 30 minutes. )

Talk to other architects / users that are using the tools, designs, etc. and
see what they are finding out. Be ready to share back what you find. "Hey our
review and POC of Astroscript figured out that getting any useful logging out
of it was impossible, so we are punting"

Be a nice person. And remember, someday you may end up working for one of
those co-ops.

~~~
solarengineer
Thanks for sharing :)

