We are trying to get more "remote" than what we currently are. I think it's a very sound strategy for anyone that's part of the software industry, specially if you'd like access to the best team out there you can get.

Lot of folks don't believe in a remote culture, and they keep shouting that not being next to each other leads to an inefficient work environment.

I don't believe that's true. I think it'll probably be more inefficient than having the same team collocated, but it doesn't need to be inefficient at all.

Keep in mind that here we are talking about the same team. If you want to hire from outside that circle, the equation changes really quick: a remote environment with access to the best talent will certainly outperform a collocated one with a limited pool of people to choose from.

So if you have a team that already works from the office, and if you believe that that team will probably be more inefficient working from home, is it a good idea to make them work remotely?

If you want to grow that team, the answer is yes. Even if you aren't planning to add anyone else in the coming years, somebody will probably leave and you'll have to fill that void, and having your whole team working from one place while plugging holes with remote people is always a bad strategy.

Remote work is not just a fad that will go away. Companies that don't embrace it will have to compensate giving something else to stay competitive. The question becomes how much are you willing to pay when the time comes.

Shifted Up

I thought it was time to make the move and name by blog something different than my own personal name. People always had a hard time spelling the URL which is the one I've been using forever.

Don't ask me why I chose "Shifted Up", but I like it. I already moved everything to the new domain and all the old references redirect appropriately.

Now it comes a long wait until the whole Internet (Google) recognizes the new domain.

I've tested a lot before pulling the plug, but I wouldn't be surprise if something breaks now that the new site is up and running. Please, if you see anything broken, let me know.

About multi-functional teams

Some people really like the idea of having multi-functional teams. (Anyone from the agile work will probably tell you this is, as much as possible, the way to go.) A team where everyone knows how to do anything that needs to get done in order to build a product.

Some people hire specialists instead. Designers, front-end developers, back-end developers, user experience specialists, quality assurance, copywriters, etc.

A friend from Dominican Republic asked me whether I prefer a multi-functional team or a more conventional team where everyone is sort of an specialist doing specific things.

My answer is that it depends. More specificly, I think you should strive for getting as much as you can from both approaches.

First of all, for a complex field like software development, I think it's extremely hard to find a team that's completely multi-functional. Sure, you can have a designer that knows how to code HTML pages, and a front-end developer that also knows database design, but the more complex it gets, the more "specialized" you'll have to get to find the required expertise.

(I don't know about you, but I'd rather have a security specialist taking care of my bank's system. Nothing against designers, but I prefer a person that lives and breathes security to be in charge of that.)

On the other hand, having a team where everyone can do it all is extremely versatile and flexible. Anyone can pick up the slack of another person and the overall productivity of the team will be really high. The number of possible bottlenecks by having someone busy is reduced because anyone can work on anything at any time. This is really cool.

As always, I think there has to be certain balance.

Identify the things you have to do and determine whether they deserve specific knowledge. If you are working on a simple website, you might try to push for more multi-functionality, but if you need more complicated and specific behaviors, you might need to look into someone whose focused only on that. Sometimes, you don't even need specialists as part of your team, and you can get away using them as a consulting role. It really depends how much you need from them.

In my experience, complex and long applications require more specific specialities in the team, while simpler, shorter projects can get away with the do-it-all type of person.

The last thing I'd say, is that no matter where you end, always try to be as multi-functional as you can. Even if you have 5 people with complete separate responsibilities, make sure they understand what a "Team" concept is and how it functions. The more they help each other, the better your journey will be.

Developers, testers, and the communication between them

You know something that developers are really good at? Blaming other developers. Another thing? Fighting with quality assurance people.

Joking aside, I think is human nature to be defensive when somebody else holds a title that allows them to review and approve your work. (I personally struggled with that idea for a long time, but finally made peace with it.)

Having a QA person dedicated to make sure your work goes out the door flawlessly is a blessing. These are people that dedicate every hour of their working days to give you all the information you need to correct your own mistakes. We should be eternally grateful about that. Every single day.

Here is the catch: if you want the good stuff that comes from having a QA team dedicated to you, you need to make certain adjustments and learn to work with them.

More than anything else, I'm thinking about communication: a good team fusions developers and testers in one, not separate silos that can't talk to each other (or can, but it's extremely cumbersome and inefficient.)

When organizing a team, this is a good place to look at: How to maximize the information that's shared between these people? How to make sure knowledge is promptly disseminated and acted on by both sides? How can you get everyone to communicate efficiently and effectively?

(This is one area where I think remote work helps a lot. Being able to talk directly to people is a double-sided sword when discussing tasks to be implemented. Although you are maximizing efficiency in the short term, you are putting a lot of pressure in everyone's memory three days from now when trying to remember that same conversation. Working remotely forces everyone to over communicate in writing.)

I'm not sure I'll ever get every single developer that works with me to love our QA team, but I'll try. For now, I'm happy seeing how much progress they are making communicating with each other.

P.S. If you are a developer, and you happen to work with a person that regularly tests your code, stand up from your desk and tell him/her how much you appreciate it (an email will also work.)

Computer Science Courses that Don't Exist, But Should

Really enjoyed this short post from James. He nailed it with his 5 courses that don't exist but should. I wanted to add another three to the list:

CSCI 1700: Naming things: An introduction to the fascinating world of naming conventions and the use of acronyms. Discover how every language does things differently, and learn 1,001 abbreviations that you'll need to know to understand people's code.

CSCI 1810: There's no such thing as a 5-minute task: A journey through the world of estimating software development tasks where you'll learn than 5 minutes is not enough time to do anything valuable (so you can stop using it right away).

CSCI 1870: Everyone's code is equally bad: Discover how bad your own code is when you read it after a week of writing it. Learn how to respect other developers and understand the value of collaboration over the illusion of being right when you aren't.

To manage technical debt all we need is discipline

I've written before about technical debt. I'd like to write some more about it, but this time about the way we try to keep it in line.

I've found that working on technical debt is not (and probably will never be) a sexy topic to talk or think about. People don't necessarily see it as something important, or at least not as important as everything else they are scheduled to work on. This is why working on technical debt is more about discipline and being consistent than anything else.

(Of course, there's no single company, or blog post, or cool kid that will tell you that they don't care, or don't do anything about it, or don't have a mastermind plan to keep debt low. The truth is very different: most people talk about it but just a few do something valuable.)

You can probably rally your time around the idea. They'll see the importance, they'll get motivated, they'll do it for the first time, maybe a second time as well. But by the third time around, something more important will be on the line. It only takes postponing it one time for the entire process to come down and collapse.

As I said, like taking the trash out, managing debt is not sexy but very important. You have to be disciplined about it. Motivation helps, but you won't find it frequently enough.

In one of our teams we started the following cadence:

  • One Thursday every two weeks is fully dedicated to work on technical debt. Not negotiable.

  • As developers, we own the debt backlog and we keep it updated along the week with everything we find we'd like to change.

  • When adding an issue to the backlog, we classify it using one of the following criteria: easy, medium, large, insane.

  • When Thursday comes around, we meet for 30 minutes, prioritize the backlog, and decide what will get done.

  • At the end of the day we update the backlog with our progress, and move on until next time.

(One thing I'd like to introduce to close the day is a code review session before updating the backlog. I'm waiting to establish a better rhythm with the team; one change at a time.)

We've been doing this for several weeks now. Not perfect (I'm still fighting with the team the idea of whether this is really important or not) but at least very consistently. I think that's the key: do it enough times and it'll become second nature and an indispensable part of our process.

I'm sure you are doing something different, and I'd love to hear about it. How does it get done in your organization? Let me know.

Better to look after the product, not my time

Sometimes I feel the urge to go back and negotiate more favorable terms for me or my team. (I'm talking about features in a software system, not money.)

The client wants to implement something. Sometimes is better for us if they want fewer things. Maybe if we do some of them different will also save us time. My reaction is to always stand up, and try to change the client's mind.

That's not necessarily bad, but only when we are thinking about the final product, and not our own time. When I'm acting as the client, it really makes me mad having people trying to change my mind just because it's more convenient for them.

There's a huge difference in the conversation when you approach it from the product's perspective, and not your own self(ish) interest.

I'm teaching myself to suck it up and live up to the expectations that were put on me and my team. Unless I have a valid reason to change something, I'm pushing forward to deliver it all. I want to always shoot for more, not less.

If you don't know what else to do to contribute

Sometimes it's hard to know what to do to contribute to your company. Of course, besides coding all day long.

I think the best approach is to ask your manager.

But maybe you don't have to because I can convince you to use any of the following ideas:

  1. Find a relevant book. Read it. Use something from the book in your current project. Socialize it with your team.

  2. List (in order of importance) the three biggest technical problems you are facing with your current project. Propose a solution for them. Lead that charge.

  3. Make yourself responsible for managing the Technical Debt in your project.

  4. Come up with three ideas to delight your client or users. Three things that they aren't paying for, neither expecting them. Three things that will delight them.

  5. Find a process that's clunky for your team. Find an existing tool that fixes it. Socialize it with everyone. (Here are some examples of relevant tools in this category: Postman, PageSpeed, MailTrap, Loggly, Crashlytics, HockeyApp, RequestBin, ...)

  6. Are you doing Scrum? Fix it (I know there's stuff that's not working fine.) Aren't you? Then fix whatever process you are using today. Here are some questions to get you started.

  7. Go ahead and find which one of these will help you get to the next level: TDD, Continuos Integration, Pair Programming, Code Reviews, Refactoring.

  8. In your project, work in any of the following three aspects: Performance, Scalability, Flexibility. Propose solutions to improve any of these (or all three).

  9. Everyday find one task that if delegated to a teammate will make the whole process move along more efficiently. Talk it through and try it out.

  10. Help your teammate become as good as you are.

All of the above are related to software development. That alone will be a great start.

There are more questions, but here you've got 15

Today I thought about these. Useful every time I want to help:

  1. Does my team have the hardware they need to do their jobs? Is this hardware functioning in an optimal way? Is there anything that will make them more efficient?

  2. Why is my team staying late tonight? How can we avoid this from happening again?

  3. Is my team having lunch/dinner every time they are working past noon or after hours? Am I taking care of them?

  4. Are my designers communicating with developers and making sure they are creating "doable" designs?

  5. Is the approval process for designs taking too much time? Is it optimal?

  6. How are my designers receiving feedback? Is it consolidated? Is it clear? Is it counterintuitive?

  7. Are my designers enforcing a creative review process? Are they overlapping (and duplicating effort) with QA? How is this process working?

  8. Why is it taking too long to move tasks from Development to QA? Where is the bottleneck? How can we increase throughput?

  9. Is QA receiving enough details to test? Are developers commenting on what solutions they implemented and informing QA how to test?

  10. Is our Scrum backlog ready for grooming? Is it ready for Sprint Planning? Do stories have enough details to be clear?

  11. Are we properly prioritizing Stories and Tasks in the middle of the Sprint? How are we deciding what to tackle first and what should come last?

  12. Is it my team too big? Too small? Are they communicating efficiently and effectively? How are we dealing with remote team members?

  13. Did we talk about our problems during our last Scrum Retrospective? Did we solve any of them? What are we doing to prevent them from happening again?

  14. Are there any tasks taking too much time? Can we optimize them?

  15. Are we shipping? Are we gilding the lily?

There are more. So many more.

My team

I'm really picky with my team. It's not only about who gets in it, but about responsibilities in general.

I like people to be able to pull their weight. I like people to be extremely valuable, not only as individuals, but valuable to the team as a whole.

I like to start with the bare minimum, and grow only when absolutely necessary. Even after growing, I'd rather scale back down as soon as I can instead of staying big and fat and slow. Less is usually more for a team.

If someone doesn't know what to do, that's a problem (probably my problem). I prefer people doing too much than people not doing enough. I can help really easily with the former. The later is a nightmare.

I want my team to be as efficient and effective as I could possible dream. People, roles and responsibilities are three really important things.

But of course, this is just me. Just my team.