Working in multi-national companies has its highs and lows. So far this was my sole experience since graduation. I do not regret it. It allowed early exposure to things I have never dreamt of at such a young age: collaboration with teams in US, India, Israel, UK, Sweden, France (just to name a few: my passport was full of visas only 5 years after hiring), working with cutting edge technology (really! working on next generation processors is an unique feeling) or exposure to icon companies (I still treasure the feeling I had when was assigned to train Ericsson’s team on a VoIP solution – I could not believe that I will be teaching Ericsson engineers on telecom topics – I was 27).
Besides exposure to bigger projects, bigger clients or working with teams around the world, there is another idea that is usually associated with big (multi-national) companies: overhead (also known as process or methodologies). It is said that if you work in a big company you have to admit that things will no longer be done fast and smooth. Instead you will be cluttered with procedures, policies with exotic roles with fancy job descriptions and with templates that will both slow-down and constrain your next move.
I do not think that this view is entirely false. But I also believe that it is too simplistic to think like this. I remember a team meeting back in my Freescale days where we were complaining that “Freescale is doing THIS and Freescale is doing THAT…”. At some point, our manager stopped our whining to ask a simple question: “Who is Freescale?”.
It’s easy to throw the blame on an abstract concept like a company. But really, if we are honest with ourselves, in any company (big or small) our way-of-doing-things is influenced by a limited number of people: our teammates, teams we are collaborating with and some support roles that connect us with the customers. This is our world and it is up to us to shape it the way we want. And if we have clutter around us, we may be the ones causing this – not THE company.
Why this clutter? I believe that the main reason is that we often forget what is really important and what is NOT. More important, we fail to differentiate between the end-goal and the things that help us achieve that end-goal (I call this support-functions). And when these support-functions slowly become the main thing that we care / talk about – that’s the moment when we loose focus. That’s the moment when we no longer work on what’s really important. And this has nothing to do with a multi-national company (but it seems like such a company is a perfect environment for such situations because big projects / teams typically need support-functions).
Let’s take a common example: we have a product that needs to be delivered to certain clients. What’s THE important thing in this case? What’s THE end-goal in this case? Simple: to deliver the product that our customers want. Everything else falls in support-function area, something that should help us reach that end-goal but should not be seen as end-goals. And when we shift our focus / energy FROM doing the things we need to deliver the product TO perfecting the support-functions, when we value MORE the output of the support-functions THAN the actual end-product – then we get into troubles. Don’t get me wrong: perfecting the support-functions in order “to deliver the product that our customers want” is the right thing to do. What I am challenging here is perfecting the support-functions for all the OTHER reasons. Here are some examples…
Development methodology. Projects usually start by selecting a development methodology to put some structure around the development activities performed by a team (that’s the main purpose of a “development methodology”). Depending on the project we choose Waterfall, Scrum, Kanban or something else that seems appropriate for the current project (the realization that there is no such a thing like one “development methodology” that will handle any type of project is, to me, the first sign that I am talking with an experienced engineer…). So far, everything is fine. The problem comes when we go deep into project execution and we discover that the project particularities force us to no longer be compliant with the way the methodology is described in the books. “We have a big problem” someone says. “What we do is not Scrum. We need to change the way we do things so we can comply with the Scrum methodology”. Really? Is this THE important thing we need to focus on? To be compliant with the Scrum methodology as it was described in some books? Or “to deliver the product that our customers want”? I am not saying that we should dismiss Scrum best practices and “throw ourselves” into chaotic project execution. I’m just saying that this is approached incorrectly. My point is that such analysis (or the “problem definition”) should start from the “important thing” (the product and the client), identify the issues from this perspective (which is the only one that matters) and work from there toward solutions. And if we discover that following a Scrum best-practice will help us with the problem we have, then we should strive implementing it. However, implementing the Scrum best-practice just because “we are not compliant with the theory”… I would challenge the value of such an effort.
Design documents. A typical software development workflow will imply several steps: requirements gathering, design, coding, testing, documentation, release (and maintenance). The design process is, often, associated with heavyweight design schemes, UML compliance and low-level details burned into extremely complex diagrams. Really significant efforts is invested in creating these complex design artifacts which (I have to admit) are looking impressive and give the feeling that you are talking with an expert in the subject… still, is this THE important thing we need to focus on? Is the perfect, complete, UML-compliant, N-level design scheme our end-goal we should strive for? Or the real end-goal is “to deliver the product that our customers want”? If you put things into this perspective, you may start to understand what is the real purpose / value-added of the design phase: to present the design idea and to get an early validation from the team AND have it documented in some form for later review. Then, you may find out that just a simple drawing on a board during a discussion with the team and a picture of the board afterwards is much more valuable for the actual end-goal (creating the right product) than the heavyweight/time-consuming UML-compliant scheme. I remember that even defining some header files (the API) for a certain module was (for that particular case) a good enough output from the design meeting that helped the team to get aligned on how components should interact with each other. Then, everyone went back to work on the important thing…
A similar example is with test plans. I saw many examples where test plans easily transform into work-of-arts with huge amount of information and complex templates, with pictures, diagrams and references to other documents. There’s nothing wrong with that. What worried me, however, was the feeling of accomplishment I have seen on the face of the engineer that submitted the test plan: it is finished / it’s done! What exactly is done? For him, the test plan was the end-goal, the important thing that needed to be completed. Now, we can celebrate… Wrong! The test plan is just a tool that allows us to put some structure around testing the product features. The purpose of the test plan is to help us built the right product. It is a tool, not an end-goal. The end-goal, the important thing, is still “to deliver the product that our customers want”. Focus on that. Celebrate that.