[This episode of iPhreaks is brought to you, in part, by Postcards. Postcards is the simplest way to allow you to feedback from right inside your application. With just a simple gesture, anyone testing your app can send you a Postcard containing a screenshot of the app and some notes. It’s a great way to handle bug reports and feature requests from your clients. It takes 5 minutes to set up, and the first five postcards each month are free. Get started today by visiting www.postcard.es]
[Work and learn from designers at Amazon and Quora, developers at SoundCloud and Heroku, and entrepreneurs like Patrick Ambron from BrandYourself. You can level up your design, dev and promotion skills at Level Up Con, taking place on October 8th and 9th in downtown Saratoga Springs, New York. Only two hours by train from New York City, this is the perfect place to enjoy early fall at Octoberfest, while you mingle with industry pioneers, in a resort town in upstate New York. Get your tickets today at levelupcon.com. The space is extremely limited for this premium conference experience. Don’t delay! Check out levelupcon.com now]
CHUCK:
Hey everybody and welcome to episode 68 of the iPhreaks Show. This week on our panel we have Alondo Brewington.
ALONDO:
Hello from North Carolina.
CHUCK:
I'm Charles Max Wood from DevChat.tv and it's just us this week.
ALONDO:
Yeah! It's a little different.
CHUCK:
That means we're both twice as important, right?
ALONDO:
Yeah, I'll definitely speak a lot more than like in the past episodes.
CHUCK:
Yeah, but it's good and I'm really curious to see what your experience is. We were talking before the show and we decided to talk about team dynamics and working on different projects, and it sounds like you've worked on a wide variety of projects for a wide variety of clients and employers, and I'm kind of in the same boat and kind of been figuring out some of the things that work for me and don't work for me, and so I'm really curious to see what you have to share.
ALONDO:
Yeah, it's been a really good experience. Immediately when I left basic contracting, I was doing like a long-term contract for a government organization and guiding into mobile development. My first iOS project back in 2010 was a contract for a company for a health care app. There were four devs and I'd gone from that to several that I'll talk about, and back and forth between formal companies and independent contracting and projects like that. There are a lot of things that are different depending on the type of project and the size of the team that I think is important to be aware of.
There are reasons why everyone doesn't fit, like particular people - you see people who come through an organization, say, a company and they don't stay, or a situation where someone says, "I'd like to be independent," and they're not really prepared for the dynamic change, and so I think it's important to be prepared and aware of those things.
CHUCK:
Yup, so I'm kind of curious with your experience as a freelancer or contract developer, what kind of projects were you working on?
ALONDO:
Well the first couple actually were in health care and it was just a by-product of the relationships that I had. I had a friend, a really good friend of mine, who's an iOS developer who called me up one day, when I was still doing Windows development and he says, "Hey, would you like to start working on some iOS stuff?" And I'd worked on an open source project for a mini-conference and that's how I got on the radar. I said sure, and so the initial projects were for these health care companies that were just outsourcing their iOS development. They didn't have in-house talent and they decided that rather than hire some developers, they would just have this project that they would just build, we would give them the code, and we would move on. So moving into that arena, that first experience, there was a lot of freedom and a lot of leeway. The client didn't have expertise in the area; we did, but we didn't have domain expertise, so that was the relationship. They provided the domain expertise to tell us the things that they needed the app to do, the rules, and we would make it happen, but it gave us the flexibility to make the kinds of suggestions about what an app should do and how an app should behave and even, to some degree, how an app should look, within limitation, that you don't always get.
CHUCK:
Yeah, that makes sense. So was it just you or were you working with a few other folks?
ALONDO:
The original project was a team of four. There were four of us that would just meet up at a coworking space, which is one of the reasons why I love co-working, and we would occasionally go to a client's site for meetings and/or demos, but most of the time, we ship that code across the wire. We did most of our project management remotely, and it was a great relationship because it allowed our team to have its own personality. You hear a lot of times about Skunk Works’ projects and companies where they sort of let employees go off and do their own thing and they're not really tied to the company culture so they have the freedom to explore, and that's what it really felt like. We were independent. We were solely working on this project, but we were fully funded and supported by this client, so it gave us the foundation of not having to worry about finances or anything like that, while having the freedom to really make the best application that we could.
CHUCK:
That makes sense. I'm kind of curious. Do you think it made a difference that you were all in the same place?
ALONDO:
I believe so, initially. I think one of the things, and I've seen this several times, that it really is important for team building. There's this concept of sort of storming and norming and forming – and I know that's not in the right order; I think it's forming and storming and norming – for building a team, and the initial weeks we spent together to build a rapport, to get to know each other, because I didn't know two of the devs. One of the devs and I were really good friends - we've known each other for years - but the working together is the important part. It's one thing to have friends and to have colleagues that you see and you know. It's quite another thing to work with them, and to understand the different work styles and the way that people like to code, and how people will respond to criticism in discussions about particular directions or code reviews. So it's really, really important, I think. Later in my career, a couple of years later, I took a full time job, became a full time employee with a company that became remote but I spent the first three months working on-site with the other devs and again, I think that really helped to build that team cohesion. That being said, I'm not suggesting that you have to do a long-term, on-site, all-body, all-hands on deck sort of development process, but I think if you can at least get one or two weeks where you can really start to build an interpersonal relationship with your team members, it goes a long way to helping to fuse a lot of things that could be misunderstood later.
CHUCK:
So the last couple of contracts that I worked for more than a little help here, a little help there – because I do a little bit of that too with things like Redmine and Instructure Canvas, which are open-source projects, and so I just help people get them set up or figure out why it's not working for them. With a lot of these other - I took two contracts where I was just part of a contracted team, a remote team, and in the first case, they had part of the team on-site and then they had contractors all over the place that were working with them on stuff. It was kind of hard to really break into it. The other problem with their particular app was that they had - so this was a web app in this case, and they had actually broken it up into multiple parts, so they had a service oriented architecture, and each of the services had been built by a different consultancy.
ALONDO:
Oh.
CHUCK:
And yeah, the whole thing was just a complete mess. So figuring out and on-boarding was really hard especially remote, where I couldn't just sit down with somebody. Now I spend a lot of time on Screenhero and Skype doing that kind of thing with them to try and get on board, but it was really hard to get engaged in the project, and then I kind of need to engage in order to really want to work it, and so that made it really hard. The other one was a similar thing. The team was much more cohesive and they were all remote from all over the place, and at the same time, again it was just really hard to engage because there was so much to know, and everybody was sprinting ahead, trying to get the next release out. I think being remote contributed something to do that, but I think a lot of it also was just that they never really had a focus on on-boarding people.
ALONDO:
Yeah, that's the critical component. When I joined the company a couple of years ago, that was a big part of the process. In fact, my role after we did the initial rewrite, there were four of us who did the initial rewrite of the app, and then we started to grow the team – I really have some really strong opinions on team size when it comes to projects like this or products - but as we started to onboard new developers, I typically would spend one or two weeks paired directly with that new developer just to get them acclimated, not necessarily to development, because many times they weren't junior developers, but just to how we worked as a team, and to make sure that we're adding people and building that cohesion and trust which I think is really important, particularly if you work in remote. Trust is such a huge factor, and being able to depend on people to get things done and giving people the freedom to get things done. I'm a huge sports fan and I will run sports tropes into the ground when talking about that. I'm going to avoid that today for the sake of the listeners. It is very, very critical that the organization understands that. If any team organization says, "Okay, we would like to bring on remote workers. We would like to transfer to remote workers," or just outsource a product, they really need to be cognizant of what is involved in that, and making that decision is not just a cost decision in terms of dollars and cents. There's a communication cost. You've got to make sure that the messaging, as you said before, an example where you've got all of these disparate systems that you try to integrate as part of the on-board process – you have to think about who's going to be available to communicate with the builders on getting these things done. What are their resources # allocate and what does that mean? What does that do to your schedule? What does that do to the morale of the team? It can be very frustrating. I worked for a government organization for a number of years, and I had a similar project where I was trying to tie together the different departments' data, and everyone used a different database on a different platform, and they're very protective. So I got my marching orders and they have theirs and everyone's got different parties and sometimes those parties were conflicting. Because it's one thing to say, “I need this data so I can integrate it into this app,” and another person says, "Well my hired part is to secure this data and to make sure that this information just doesn't get out to anybody." So what do you do and who do you go to make the final call?
CHUCK:
Yeah, and a lot of times it's not really that the communication wires got crossed, but that as soon as that happens, nobody knows where to go to get the answer, and so everybody's just sitting there going, "Okay, now what?" That's really a problem, so you really do need a solid project manager that can make those calls and that is in touch with the project owner.
ALONDO:
Yes and that's a trade-off, right? Because this idea of empowerment, right? We want to be empowered. We want to empower team members to make decisions, but at the same time, someone has to be a decision-maker. Someone has to sort of break the log jam up when it occurs at certain points, and that person has to be the right person in the right position in order to make those calls.
CHUCK:
Yup, definitely. So I want to talk a little bit about remote teams because I have seen them work, and I actually run my own, and it works really nicely for me. You really have to focus on communication when you're doing remote stuff.
ALONDO:
Absolutely, and that's where I think – when you form the team and you establish a rapport with each other – it’s so important. That you can depend and you can ask, you can call on your teammates and you can say, "I need help with something," if you were blocked in something. If you don't feel that you can or should communicate with your team members, then it's going to cause a lot of problems. It's going to cause stories not to get done on time and that's just going to be a chain effect that this is going to trigger a potential derailment of a project. I will say when it comes to remote work, not everyone is geared for remote work.
CHUCK:
Oh, it's so true.
ALONDO:
And it sounds enticing and a lot of people like the idea, but you really do have to be a self-directed person, because it's so easy to get distracted. There are so many things that can be competing for your attention. I actually have family members that when I travel around, they remark and say, "You get up and you get dressed and you start your day and you just go downstairs and set up like you're going somewhere." I'm like, "I have to do that. It's just part of me mentally getting ready for my work day." I had to teach as well as learn myself this process, because I had to make sure that everyone around me respected my work process, and that I am still at work. I'm using air quotes.
You can't see it.
CHUCK:
[Chuckles]
ALONDO:
Because most people think, especially those who don't work in technology who say - or are not familiar with remote work - they see you physically away from what's deemed a workplace, and they don't connect it with doing work. So they say, "Oh, I can just come over," so then you have the potential for the same interruptions you have in the office where somebody just comes by your cubicle and wants to talk about Lost or something. I'm way out of date, but –.
CHUCK:
[Laughing] Lost!
ALONDO:
I'm really far behind on television. I just started watching Doctor Who not too long ago.
CHUCK:
Oh, good for you.
ALONDO:
But you do have to make sure you create those boundaries. Boundaries are important and again, the discipline, and so I think to be a successful remote worker - and the team also has to establish rules. I worked on teams where we've had a set of what we called work hours, core work hours, where everyone's supposed to be online and available, and I've worked on teams where we absolutely don't have any of that, and you work out your own communication schedules with the individuals with whom you need to communicate, and both can work.
CHUCK:
Yeah, and really what it comes down to is just being able to get responses, like people are responsive within a timely manner, and that's what the core hours really solve is that they're responsive because you'll know they'll be there. As far as setting up your home work environment so that you're not interrupted all the time, I definitely agree with you on the boundaries issue. I have to protect my boundaries digitally as much as I have to do it physically because I'm at home and I have four kids here and so my two year old, he wakes up from his nap and the first thing he does is try my office door, so I have to close and lock the door. Most of the time, that's enough – just having a room with a door that locks when I need it to. That's enough. And my wife keeps the kids out of my hair most of the day so that I can get stuff done. But yeah, you really have to be disciplined about that. It doesn't mean that you can't go downstairs and get involved with your kids or with your family or with whoever's around, right? So if you have visitors or something and you want to spend some time with them, that's fine, but then you got to make sure that those boundaries go up when you need to go back to work.
ALONDO:
Absolutely, and it can be difficult having to deal with that, as you say, moving back and forth because, there's always a context of you taking your mind of the work. One of the colleagues I work with, he actually was home-schooling his son at one point during one of our projects, and so he needed to structure his day where he could give us two to three hours onsite at our co-working space, but he was at the co-working space because it also worked well for homeschooling and so would spend a couple of hours there as well. But it required him to sort of setup a schedule and he let us know, “Okay, I'm available here, and I'm not going to be available at this time." So you can really make it work in a number of ways, but those principles do have to be in place; you do have to have those boundaries. I'm curious about the digital boundaries. I think we talked somewhat about this on a previous show about tools, but when you talk about digital boundaries, speak a little bit about how you keep those distractions away.
CHUCK:
Most of the distractions are things like email or Twitter – sometimes it's Skype. Most of the time on Skype, people message me; I can just let it slide. But really what it is, is turning it off or being able to not give it attention. I have notifications every time I get an email and so then I have to decide whether or not I want to go and check it out. Usually what I do is actually go ahead and take care of email first thing in the morning so it's out of the way, and then I don't have to do anything with it for the rest of the day. Occasionally, something will come in and I'll check on it in the afternoon and just make sure that nothing important came in, but that's it. I don't reply to those emails after that.
ALONDO:
Now one of the challenges I found I've had even up to this day is chat. We have a team, we have multiple groups and it can really be distracting. How do you deal with that?
CHUCK:
With chat, it depends, right? I feel like if I'm reasonably responsive, then that's okay. Unless there's an emergency or something, or somebody doesn't need me because it's holding them up, then a lot of the times, I'll let them slide. With the last client that I worked on a team with, they used a program called FlowDock – you can get it at flowdock.com – and there were a couple of different nice things about that. One was that if somebody said your name, then it'll notify you. The other nice thing is that it would actually, if you replied, you could reply within the context of specific conversations and it color-coded them, so you could see the different conversations that were going on and which ones you wanted to pay attention to. You just click on the color of the speech bubble and it would just show you those, and so I could just check it really fast if somebody said my name. A lot of times I'd miss large swaths of conversation because I was heads down in the code, and then I go back and check it out later and see if it was important. A lot of times too I just turn it off. I just tell them, "Look, you know, I'm really going to be focusing on this feature, so I'm shutting down Flowdock, and I'm shutting down these other things. If you need to get a hold of me, then this is how you do it." And so I leave one channel open for them to reach out to me if they really needed my help with something, and then the rest of the time, I just shut it off. But most of the time, it was fairly non-intrusive to keep it open, so unless it was really active and really distracting, I'd usually just leave it open.
ALONDO:
Okay. Yeah, that's one of the challenges we're having now is I've got to learn to incorporate some new ways into the tool that we're using to allow me to get pinged when it's important but to sort of avoid - because we have some fun channels and some generic channels that can be very, very distracting. We've got SnapBot running in there that's like someone types in a word, or post a picture or a funny image or something, so you really have to be mindful of that and say, "Okay, I don't have the resources right now to allow that to get in my way.
CHUCK:
Yeah, and I found that most team members are actually pretty okay with you saying, "Hey look, I
really need to get this done. I really want to focus on it. I'm going to step out of chat for an hour," and then you know, you just set a timer and get back in an hour. Just things like that; just make sure you communicate. And really I can't stress this enough – communication's really the key. It's the key when you're in the same office or room every day, and it's the key when you're remote. You just got to make sure that everybody knows what's going on, where they fit. You wind up saving yourselves a whole lot of trouble and effort there where people might go and repeat work, or they might do something wrong, or things like that. If you're communicating well and everything is welldocumented then you solve a lot of those problems, and part of that is the chat thing, and part of that's your ticket tracking or whatever you use for that.
ALONDO:
Yeah, absolutely. I would agree. I tell you the one thing that I would add too is that I find that reaching out and having communication can also reduce stress. It allows you to not get - I've been on projects where I've been on an island, it's just me, and there was really no one other than the Interwebs to try to find a solution to a problem or get a second opinion. But when you have team members and you can communicate with them, you really do have a sense of comfort knowing that you're not in it alone. I find that it helps, especially in problem-solving because I need all of my faculties to put towards actually solving the problem, not spending cycles being worried and it comes out as a waste of time. Communication – you're absolutely right. That would be the hallmark of a successful team and a successful project.
CHUCK:
Yeah, and when it comes right down to it, I don't know how much of a fan you are of agile development – and I'm saying agile in the general sense, not the capital-A-Agile, follow-amethodology, be-a-religious-zealot-Agile. That's really what it's about. It's about communication and solving those problems and it's about finding what works for you. Every team kind of has to go through that process of figuring out, "Okay, this works. This doesn't. This makes a big difference. This didn't make a big difference,” or “It hurt when we tried it." But it really is – the first one is – I can't remember exactly what it is, but it's like people in collaboration over a process in the agile manifesto, and that's really important because if you have a process, but you're not communicating well, then you are going to fail.
ALONDO:
I think you hit on a really important piece of having a successful project there with regards to whether or not you're using Agile, and I'm curious because I've been in some situations where our team workflow is not necessarily the same as the client's workflow, and we've had to adjust accordingly. For instance, we may not necessarily be doing the Scrum practice the way that they're doing it or having two-week sprints, but because the client wants deliverables in those increments, then we've had to sort of accommodate that and I'm curious as to how you've dealt with that sometimes. Particularly when it really flies in the face of - say for instance, have you ever encountered a situation where you're doing Agile-type practices and someone's still on Waterfall as far as the client? I don't know if that's still a thing.
CHUCK:
Yes and no. I mean everybody's kind of in their own place and they value their own things in a particular way. One thing that I found that really helps is if you can get the project owner to be part of the team. They're not necessarily - they don't get a vote on like estimations and things, but essentially they come in and they're able to tell you what they need, and why they care, and what's important about it, and then if you can convince them to trust you, and that's the other bit, right? It’s the trust that goes between the two groups. They trust you to deliver what they've asked for, or tell them why you can't deliver what they've asked for. So if they're saying, “I need this and I need this in this time frame,” you can tell them yes, no or whatever, and then tell them why and help them figure out how to get as close to what they want as possible. And you involve them as though they're part of the team and part of the decision-making process, so instead of them delegating to you, they're actually collaborating with you. It makes a huge, huge difference.
ALONDO:
Yeah, I would definitely say that's the change that I saw when switching from some of the more traditional waterfall development I was doing before I got into mobile and then transitioning into Agile, is the fact that the project manager was someone from product or someone from the client company, and we did have that relationship where there was the trust, and also that understanding because of the collaborative nature, we're getting clearer ideas of what it is that's needed. And so we're able to constantly iterate on that because if you just get a block of requirements and you're shipped off to just go build it, there are a lot of things that can happen between the time you start and the time you deliver something that could cause you to deliver the wrong thing. But having someone who's invested and having that trust – I mean I've had experiences prior to that where someone would sell a feature and just come back to us and go, "Oh, I sold this last week, can you guys build it?" And we go, "Okay, thanks a lot. You're not really working with us." Whereas with someone who's a part of your team, even though they do have priorities and things like that outside of the product development as it were, you still have that trust and you're able to depend on them, and they can depend on you, and I think you have a clear goal and it's more transparent and it definitely lends to more successful projects.
CHUCK:
Yeah definitely, and the other thing is that when they come to you with that, "Hey, I just sold this feature, can you build it?" That's not collaboration. That's them assuming that you are going to work for them, and it just never works out well. Well, I can't say never, but it doesn't usually work out well.
ALONDO:
Well if you flip that on the [inaudible] too, when you have that trust, even as a team, they're willing to say, "Well we understand that sometimes things change coming from outside," but they know it's not you as the project manager, and you're willing to in a lot of times like, "Okay, we're in this together. We know that our order's changed. We'll band together to get that thing done as best as we can,” versus having an adversarial relationship of, "Why do you guys keep changing these requirements?"
CHUCK:
Right and so then what happens is it's a collaboration thing and so instead of saying, "Hey, I just sold this feature. Blah-blah-blah," it's "Hey, I was talking to this customer and they want this feature. How does that impact things?" So then you start having the collaborative sessions where you figure out whether or not it's possible or what would make it possible.
ALONDO:
It's amazing how just that changes that conversation. We can take a slightly different angle on how we view things in that perspective. It does so much to determine what kind of outcome and even how we get there.
CHUCK:
Yup. One other thing that I want to bring up harking back a little bit to on-boarding, and you mentioned this before the show that you've worked for places where they need more work done so they hire more people, and I don't know if you've read The Mythical Man-Month?
ALONDO:
Oh, yes!
CHUCK:
[Chuckling]
ALONDO:
It was required reading in my CS program.
CHUCK:
Yeah, same. They don't just get that so what they're thinking is, "I need to get this done by the end of the month and so if I hire ten more programmers, then I'll get ten times the work done before the end of the month, right?" And the analogy I always hear makes me chuckle a little bit is nine women can't have a baby in one month.
ALONDO:
Absolutely! I've actually used that in response to someone saying, "Oh, we'll just bring in more devs." I'm like, "Mmm I don't think that's going to work."
CHUCK:
I mean if you're working towards a deadline that's six months down the road or something and it takes you a month to on-board somebody, like to really get them contributing, that may work out, but doing it the other way, just by the time they're up to speed, you've already missed your deadline.
ALONDO:
Pretty much, and one of the things that Brooks talks about in that book too is as you're adding these other communication points, these nodes or people, you now have that many more points of failure, that many more points of breakdown, and you really do have to be mindful. As you say, it's not you can't do it, but you really have to be aware. So I'm a stickler about growing teams and how you do it, because I was a part of a team that started out with 3 or 4 devs and grew to 12 mobile devs, very quickly. The types of developers that we were bringing on, I wanted to make sure that we knew what we were getting into, because I know higher up there's a different mindset. So like, if we throw resources at it and these resources aren't as experienced but they're less expensive, and we just place them with the more experienced resources – there should be no problem, right? And that's not necessarily so. The expectations for junior developers really has to be set. You really have to understand what it means when you're bringing on a less experienced developer. Not just less experienced in development as a whole but even less experienced on that particular platform, that particular language. You really want to make sure you don't have the wrong expectations because that comes back and can have a negative effect on that person's place in the team when you're evaluating them. It can have a negative impact on how other teammates view that person and how that person views their experience.
CHUCK:
Yup. The other thing that I find that’s really interesting with a lot of this is just, and you kind of alluded to it when you were talking about the team size and adding more nodes of communication or more people to the team, is that I found that most teams have an optimal size and it's not the same for every team. Some teams really gel well - the 8 guys or 8 girls or 8 whoever on the team or you've got other teams I've seen that have up to 15 or 20 people, and I don't know how they made that work, but they seem to make it work. Most of the teams that I've worked on, the ideal size was about four or five, and then what you wind up doing is you could have another team of about four or five working on a different aspect of the product, and just make sure the inter-team communication worked well. It's really interesting to look at that and go, "We need more devs," and so you just dump a whole bunch in there.
ALONDO:
I agree. I think, and it's funny you said four or five, because that's exactly the number I had in my head. I look back on all of the projects that were successful and great work experiences and we had a great team dynamic, and there were between four, maybe six, but once you get to six, we typically are dividing the labor up in such a way that it's probably two teams of three. But you're right. If you can divide the product in such a way that it makes sense, you can be successful with larger teams, but it's the [inaudible] edge about too many chefs in the kitchen. You can't really have every one trying to make soup at the same time. It just doesn't work.
CHUCK:
Yup and the other thing is you talk about dividing it up so that it makes sense. You have to understand that if you split it up into two teams, the weakest area is going to be the area where the two overlap. So if you have two aspects, maybe the frontend UI display and the backend logic and stuff, your weak point is going to be where the two meet, because both teams have responsibility for it and neither team really has responsibility for it, and so they have to communicate really well about that boundary, because if they don't then that's when your problems are going to arise.
ALONDO:
That's an actually excellent point. I never really thought about that. Now I'm going back to my mind on all these projects, thinking about the sticking points, and I think that's exactly where it's happened.
CHUCK:
Yup. Well that's where you have problems with say a mobile app and the API, or you have a problem on web apps – the frontend and the backend. It's because they were designed to work together but they were designed by different teams with different communication styles and so you'll just run into those problems. If you're very aware of it then you can have a project manager or a couple of project managers and maybe some team leads involved to make sure that that communication happens and is very clear so that the expectations from the frontend and backend and vice versa are very clearly codified and everybody knows what they're supposed to be doing.
ALONDO:
Okay and that was my next question about that is like, how would you structure that, and it sounds like what you said. The team leads are communicating with each other and it's their job to sort of disseminate that and make sure the rest of their perspective teams are on board and up to date with what's going on. That makes sense. That makes sense
CHUCK:
And it's funny because it comes right back to the same thing we were talking about where it's a failure of communication that causes the problems.
ALONDO:
Indeed. Communication is such a - it's sort of like the light of business and projects.
CHUCK:
So I have to ask, have you ever worked with any of those developers that were kind of the toxic force on the team, or just didn't quite fit, or were kind of even just plain out and out problem developers?
ALONDO:
Yes in fact, I would never name names, but as soon as you said that, the image of the person immediately popped into my head. Yes! It's really difficult and it was one of those situations where this individual was the API developer – a necessary point of communication, necessary person to deal with on a daily basis in order to get things done, and just had a personality of –. That's the one thing about understanding people that can help diffuse some of that. When you understand the back story about why and personally, on this one, it was just the person wanted to be a part of the mobile side and didn't get that opportunity so they had a little bit of jealousies at work to be working on a new [crosstalk]. It came through in a way that they communicated with the mobile team members and it was one of those things that got to a point where we really did have to stop and say, "Wait a minute. Just communicate civilly with each other." Because it got a little nasty. At that point sometimes, unfortunately, you do have to maybe bring in some higher ups to kind of clear the air and diffuse things. I haven't had many experiences with that, thankfully. I pride myself in being able to talk to people and developing really good rapport outside of work, so that even if we don't necessarily agree on everything that we can always be civil and respectful and we can work together just to get the job done.
CHUCK:
Yeah, I found that in a lot of cases, you know, if you talk to them and kind of figure out what they're problem is and find ways to accommodate them, a lot of times it will fix it. And so yeah, it's really just interpersonal stuff. Anybody who thinks coding isn't a people job hasn't worked on the right teams, to be honest, because you figure out pretty fast that people matter more than the code does. You won't get anything done.
ALONDO:
It really does. It really does. People take their code personally, you know, and you have to - I had a manager once and she was mindful of it, though. She really understood. She would actually even approach situations like, "Okay, before I even... Just know that this might have impact on the code just to prepare you mentally for what's going to happen." Because she understood that. She knew how you take pride in what you do when you care about it. You care about your work so you can't help but take it personally. It's not just bits.
CHUCK:
Yup, so I've worked with two different types of problem children, so to speak. Well three if you count the project manager that I dealt with at one of the clients I worked with. For the most part, some people just, you know, they're going through a tough time in life, or they've got something , you know, they just have a bad attitude about things. If they're going through something, a lot of times, a little bit of sympathy or empathy will just solve it, and then you just give them a little bit of space and understanding because they're dealing with something that is genuinely hard in life, but I've also worked with people that are just negative people. Honestly, after everything that we've tried to do with them, the only thing that was left to do was to let them go and if you do everything you can to make it work, and you just can't make it work, then you have to – for the sake of the team, for the sake of a project, for the sake of everybody else, because it's not fair to make everybody work there and it affects everybody. So just let them go. And I hate to say that about anybody, but ultimately it is something that has to be done, and if you're running the team, then that's what you've got to do, or if they're not pulling their weight, it doesn't matter how nice they are, the team feels it, and if they're seeing somebody else skate by without delivering results, they're going to be resentful or worse, and worse being that they slack off or sabotage the project. You really have to pull in and make sure that everybody feels like they're appreciated and that their effort is recognized, and having somebody on the team that's not doing it is going to undermine all of that.
ALONDO:
Now here's a question about that situation. What do you do when that negative person is in a managerial or higher level role and you can't simply dismiss them, or they can't simply be removed? We had a prior project I worked on some years ago where we had a person like that that was a higher level management person that was directly involved in the project, and we nicknamed him the seagull because he would just swoop in, he would squawk, and he would just leave, let's just say, negativity, and then fly away. And that was a person that we couldn't – even a as a team, even as a project manager – do anything about.
CHUCK:
Yeah, I mean, the only thing you can do is raise the concern above their heads. So I can think of two people that I've worked with that were like this. One would come in, yeah, and we'd use the same analogy, he would come in, crap on us and leave, and with him the only thing we could do was we talked to our manager. We talked to the CEO, and ultimately, there was nothing we could do. I think they talked to him; it didn't make any difference and so we just kind of had to deal. The other instance was a little bit different. I was actually running tech support for a company out here in Utah and my boss –. I had built the tech support team, trained them, I was running the team, and then they hired somebody to come in and manage me and my team, which made some sense because I didn't have the kind of experience that they wanted there. Anyway, they hired this guy to come in and do this. By the way, I haven't told this story to anybody, and the person who is involved here will probably know who he is if he listens to this show, but I don't think he does. So what happened was eventually it turned out that he was lying to a lot of the people underneath me about what they were getting paid. Some of the guys went in and said, "Hey, we feel like we deserve more," because they were kind of the original people that I had hired and were really kind of the key players on the team, and they had got wind that some of the other people that had been hired were being paid more and he told them that they weren't, and it turns out that the one person that they were concerned about was smart enough to leave his pay stub out, so they found it and figured out that they were being lied to. There were repeated issues where they would go to talk to him and he would, through the window, kind of wave them off without realizing that while he was waving them off, they could see on the reflection on the whiteboard behind him that he was playing Solitaire, and so he was waving them off just to play Solitaire. Just stuff like this where he wasn't a negative influence but he wasn't a helpful influence and nobody felt like he was part of the team, and really, nobody had respect for him. And so eventually, I had to go to the CEO and COO because half of my team was on the verge of quitting. And so I went to them and I said, "Look here's the deal. Here's what's going on, blah-blah-blah," and within two hours, he was being escorted from the building. They took care of the problem. And problem solved, we kind of ran things from there. I would up reporting directly to the COO who I eventually then had issues with, but that was a different story. Anyway, it's kind of what drove me into being a professional developer, actually, because I was in management at that point. I was on a management track, not a technical track.
ALONDO:
There's one thing I was going to say when you were mentioning that in that story that that was communication that was taking place. It was just negative communication from that individual and it was very clear that he was dealing with it really bad. I think about that sort of dynamic you were transitioning into moving from a managerial role to a technical role – have you found a lot of projects where you had to straddle that fence or are you able to keep a toe in both pools?
CHUCK:
So at this point I've built up a remote team. We mostly do web applications, though; if you can't tell, I'm very interested in mobile. I've been doing this podcast for a while now. So yeah, I wind up straddling that. The difference is that when I report up, I'm reporting up to a client, and so I have a lot more pull with what goes on, and I can quit. The situation is a little bit different. If they're a toxic client, A, usually I'm the only person who's really dealing with it, and B, if I can't take it, then I'll just quit.
ALONDO:
Okay, now do you weigh in on the fact that like for instance, if you were a solo practitioner and you're doing a solo contract developer, it's a lot easier to make that decision? Does it make tougher when you have team members who are saying, "Oh, we've got this project. We've got work"? It's like walking off of a job site. You got a crew. Does it make it harder to do?
CHUCK:
It does. It depends on how much money I have in the bank and that kind of adds some influence. So if I have more money in the bank, then I have more power to walk away, right? Because I can take these guys and I can say, "Hey, work on this project for me for a while, until I find something else," or a lot of times, I could just move them off on to another project that I'm working for somebody else and make it all smooth out. I'm still a little bit new at this, but for the most part, it's there. The other nice thing there is with them, the buck stops with me and so it saves a lot of the hassle there. And if somebody doesn't fit, they're not working or whatever, they're contractors and I really can just let them go which is a lot more freedom than you usually have with an employeeemployer situation, but it is tricky. Sometimes, you don't want to let people go. I don't want to be the guy that has to let people go; it kind of ruins my day even if they deserve it. But at the same time, I
have to look out for everybody else. I have to look out for my clients and I have to look out for my other contractors, and so if it's not going to work out then it's not going to work out. And the other thing is that in a lot of cases, if they don't fit well with me, there's probably somewhere else where they will fit, and I'm totally happy to help them find that, and that's really –. I think that's a good way to approach it too is, "Hey look, it seems like you don't really fit in with this particular circumstance, but I think I have these other friends here that you can go talk to and I think they have something that will fit you better."
ALONDO:
You know that's an important point too I wanted to address from the person who's being let go stand point. It's really easy to feel a lot of emotions if you've ever been in that situation. It hasn't personally happened to me although I've thought several times that it might in my career, that sometimes it's just about fit. I really don't like the “it's not me, it's you,” but sometimes it really is about fit. Maybe, as you were saying outside of the show, everyone's not cut out for remote work, and everybody's not necessarily the right fit for a particular team on a particular project and it can work out better. I would say to anyone: Don't be discouraged and think that you're not good at what you do. Maybe you're just not the right fit for that particular team and that particular project.
CHUCK:
Yup, absolutely. So I've dealt with the one kind where people are negative or I don't think that the one guy at that particular job was particularly deliberately negative or down on people, he just thought he was higher up than them and that he could do what he wanted, and didn't see the impact of what he was doing. The other toxic type – they're less toxic and they're more just not helpful – are kind of the rock star developers. What I mean is they don't think they're higher or mightier than everyone else - some of them do - but for the most part, they just really aren't good at communicating at all. What they want is they want come in, they want you to hand them a list of features to build, they want to build it all by themselves, and then go home and play with whatever they do at home.
ALONDO:
Yeah, that one's a little more difficult, because people say we want rock stars and ninjas, and then you just end up with broken bodies and broken guitars all over the place. If you get to meet those people, it's not a situation where - going back to what I was saying earlier, you really have to be aware of who you're bringing on and what you are looking for in a team dynamic. If you want that kind of developer, if you want to bring on a rock star or someone who can just go and work on an island, and just say, "Okay, I don't need you to communicate with us constantly. Just get this thing done." That's fine if that's what you're looking for, but if you're expecting someone to really be a team player and to be a communicator, or even more so, to be a leader for maybe less experienced devs or something like that you really need to be mindful before you bring on that type of person, because that person's not going to want to do any of those things.
CHUCK:
Yup, and the other thing is that it doesn't matter how talented they are. If they can't play well on the team, and that's what you need, it doesn't matter how talented they are. They could be the best programmer in the world, they never write bugs, blah-blah-blah-blah, but at the end of the day, I mean, most of the time, your application is complicated enough to where you have some parts that have to communicate with other parts and that means that the developers working on part A need to be able to communicate with the developer working on part B. And if he's a terrific developer but will not communicate, then you are hampering the entire effort, and he'll probably be more of a hurt than a help.
ALONDO:
Absolutely! I mean even if you have a healthy ego and you're confident in your skills and all these things, if you don't subscribe to the idea that the project is the thing that is greater than you, the team is more important than the individual, it's not going to work out. Like you say, everybody has to buy into that, and you see it in all kinds of teams – and I've managed to get through almost the entire show without sports analogies – but if you got a guy who won't pull a block, you can't do certain things! You can't get things done. Sometimes you got to be the guy that goes in front – and I say guy, but I absolutely mean male and female – you got to be able to sometimes go and do things so that your team members can succeed and that's not always the glamour work. Sometimes that's stuff that nobody wants to do, right? But then you say, "I'm willing to do that because it's important that that thing gets done."
CHUCK:
Yup, it's like having Kobe Bryant and Shaquille O'Neal in the same team, right?
ALONDO:
Ha ha! Yes! [Laughing] Yes!
CHUCK:
I'm just throwing it out there. I remember - I don't even remember what year it was - but the Lakers they had four or five star players. I think they made the playoffs, but I think they were out by the first round of playoffs because they couldn't play as a team.
ALONDO:
Yeah, they tried to buy a bunch of superstars kind of like you said, they went out and tried to get a bunch of ninjas and rock stars and that doesn't make a cohesive team. You can get rock stars and don't make a good band. They can't play together, and that's exactly what happened that year. You really do have to get a good mix. I think it's important to make sure that you have –. There are certain developers that are just like, "You know what, I don't mind doing what we would consider grunt work. I like that stuff. I don't mind revamping the code. I don't have to work on new, shiny stuff all the time. I don't mind working on bugs." They live to fix bugs. Or some people say, "I don't mind helping to train up junior developers. I want to get involved." And if you have a good mix of those players and it works for your organization, I think you can be very, very successful in building products.
CHUCK:
Yup. One other thing I want to ask you about, and this is something I've been thinking a lot about lately, is hiring junior developers. So it seems like everybody out there is like, "We need more senior devs," and there just aren't any. So what are your options? Well you've got to hire somebody with less experience. How does that affect the dynamic of a team?
ALONDO:
Okay, so this is where I tie it back to a couple of things that we've already talked to before because I actually had this happen. There were senior members on the team who just did not want to work with junior developers. They didn't feel like it was their job. They didn't feel like it was their point in life. They've got their own career. Everybody's got their reasons, as it were, right? And so it can become really difficult if there's not that buy-in, and you have to make sure that even if you have individual members who may not be so keen on it, or maybe are not good at it, that you still place junior members in the right positions. That's the other thing: you want to put people in positions where they can succeed. You don't want to ask too much of them too early. I've seen expectations rise a little too fast, particularly if there is a junior developer who picks things up very quickly, then they become the norm for the other junior developers, and that's not really fair. It's like saying, you know, a kid going through a growth spurt, it's like, "Well now we expect everybody else to be this tall at this age." It's like, "No! That's not how it happens." You really do have to have expectations that are realistic for that individual, and ongoing, what are your practices to help develop and nurture that career of that person to make them better? Because to me one of the benefits that you can have of bringing on junior developers and growing them is that they're the ones that will be with you a long time. They're the ones who can have that history and know the product. You may be difficult a lot of times particularly in this environment to keep senior developers. They may be off to the next big thing. And that loyalty, though, for juniors who you've established that relationship and you have that with them over a longer period of time can be beneficial, not to mention the cost benefits that can exist there as well.
CHUCK:
Yeah one thing that I think is really interesting too is, in my experience, there are - how do I put this? Because I don't want to put anybody down, but I found that there are two types of developers. There are the developers that just want a job and there are the developers that are go-getters, that will go out and learn it, and get it, and work hard and blah-blah-blah, right? And sure, everybody picks things up at a different pace and you have to be able to take care of that, but at the same time, I really want the go-getters. I want the go-getters as my seniors, I want the go-getters as my juniors, and so I really try and evaluate people based on that. Are they going to go and go out of their way to figure out how to solve the problems I hand to them if they're hard, and are they going to out of their way to just nail it on the things that they're good at? Because those are the people that really make the difference. I've worked with the people that show up, then they want a pay check. They're not fun to work with.
ALONDO:
Yeah, absolutely! And I guess I should be a little clearer with that too – I am not a proponent of paycheck quitters. I just don't think those people belong in the organization at all. I'm talking more of the dynamics, I'm assuming, the drive. I'm just saying that the aptitude varies for people who have the desire. Another sports analogy, I'm really sorry, but this one is so apropos is the basketball team in Kentucky. In college basketball, they have this won and done rule where you can't go to the pros immediately anymore. You got to go spend a year, and that program is littered with those kids, right? The coach will grab kids that they would play for a year, but you know they had potential pro-level talent even before, and if you are –. Go-getters are going to continually goget, you know? And they may not continue to go-get with you. So you have to be mindful of that when you're building your team, and it can still work with your team dynamic. You may have a higher amount of turnover, but you can still make that work, right? You can have an organization - I
know plenty of corporations in Atlanta, particularly, that they hire a lot of developers and there are high turnover rates – some because they're just toxic, some because they tend to bring in the people that want to work on a project or a product and then after a while they just want to work on something different. They want to be challenged by new projects; they want to be in a new domain. I think you can make that work if you understand that dynamic and you prepare for how you bring in, how you have these people work and in what roles, so one of the things that you don't lose is essential knowledge. The body of knowledge doesn't walk out of the door just because someone with knowledge happens to walk out the door.
CHUCK:
Right. So one other thing that I want to ask you about this is – and I'm not sure if there's a good answer for this; I think it varies from team to team and from junior and senior to junior and senior – how many senior devs do you feel like you should have for junior? What ratio do you think makes sense if you're building a team and hiring juniors onto the team?
ALONDO:
Okay, so the way that we had done it in the past was, literally - my Star Wars geekiness is coming out - is the Sith rule. Always two, there are.
CHUCK:
[Laughs]
ALONDO:
A master and apprentice, and that's how we've typically structured it. It doesn't have to stay that way and you don't have to adhere to that one, but I find that it really works well, because it allows you to solve two problems. One, you have that sort of senior-junior dynamic going on where the senior is imparting information on the junior, and the junior's asking good questions and is engaged and challenging the senior, because that's the great thing about working with a junior dev is you get challenged. When you have to explain something, you really have to think about it, and you can see things from a different perspective. The other part of that too is the part of the onboarding process of the culture. You're getting someone who's familiar with the culture and bringing someone on and helping indoc - I really want to say indoctrinate - but really get them familiar with how things are done. So not just as a career, technically-proficient, but company, culturallyproficient, so I think it works. Once you get to a certain level though, you can switch it up. I've seen it work really well where at certain point, we – what I would consider the more experienced juniors – pair a couple of them together, and just have a little bit of oversight from a senior developer, and let them go off and start to spread their wings a bit, and that frees the senior up to do some more engaging things as well, to go a little bit deeper in some areas, and allowing those juniors to grow. You don't want to keep it permanently, or even for too long where it's just kind of like this, “I'm feeding this person information” or “I'm guiding them along.” You want to get them up to speed and then start to give them work that allows them to really stretch out and move forth, but just with that sort of eye on things to make sure that the code quality doesn't shift, project schedules don't slip, and things of that nature.
CHUCK:
Right. Makes sense. Yeah, and I do like the kind of mentoring-paring idea.
ALONDO:
Yup, I'm big on pairing, and I think that I was going to ask a question about sort of success ganging or leeway, particularly with clients, a lot of times, or even with an organization that's not really keen on remote work. I was a part of a company that was transitioning to that and there was a lot of pushback because there was this idea of “if we can't see it, we don't know what's going on.” Just like bringing on juniors and getting them up to speed and getting small wins, a remote team or building rapport with a new client, getting small wins. All of these things can build confidence in the work that the team does, and allow you more latitude to do your best work.
CHUCK:
Yeah, definitely. And I think really what it comes down to with being comfortable with remote teams is that you really do have to see the results, and once you're seeing results from them that you like, then it doesn't matter that you don't see what's inside the box or under the covers, because they're cranking out enough value to where you're happy with the return on investment you're making with your money.
ALONDO:
Absolutely! Absolutely. I don't care how hotdogs are made. I just want hotdogs.
CHUCK:
Yup, and that builds trust, and that's really what it really boils down to. I tell a lot of prospects when I talk to them it's like, "Look, here's the deal. You're not technically savvy. You could learn that but it would take you too long. So ultimately what it comes down to is, “Do you trust me to do what I say I'll do?" And that's really what it boils down to for a lot of management folks is, do you trust the team to deliver what they said they would? And if they do, are you happy with the return on investment? In other words, are you happy with the value exchange that you got? And if both of those are true, then it doesn't matter.
ALONDO:
That's such a good point too, keeping that at the forefront of that conversation. Revisiting that, and like you say, having those successes and delivering results – the results really trump everything else at the end of the day.
CHUCK:
Yup, it's all a value exchange. But anyway, we should probably get to the picks because I need to prep for the next show. Do you have some picks you want to share with us?
ALONDO:
I do. Okay so I just used Kickstarter for the first time and I Kickstarted an Edison Fun Robotics Project for Inventors. It's an affordable, programmable robot backed by - it's a project by Microbric out of Australia, and it looks really, really fun. I'm really looking forward to get my hands on it. I have some younger cousins that I want to get involved in Robotics and get excited about programming, so this is going to be one of the ways that I'd do that. I'm going to post the link for the Kickstarter project. Along with that, there's another organization that I just volunteered for. I wanted to get involved with one of the members at a conference recently and I'm super excited about it for the same reason. It's Black Girls Code. They have different chapters and they hold Hackathons and I really think it's a great thing to do to get young people excited about technology. So those are my two picks this week.
CHUCK:
Awesome! Great picks! I've talked to a few girls, or a few folks from Black Girls Code, and they do awesome work, so I can't say enough nice things about them, because they just rock.
ALONDO:
I'm looking forward to the first one here in Raleigh that I can participate in.
CHUCK:
Yeah, I haven't actually been to an event, but it sounds like they really have the right idea about things. So my picks, I'm going to pick a few books. We talked a lot about people being go-getters and I have to say that there are few books out there that really kind of ring this in for me. The first one is called The Go-Getter. It's actually a fictional story; it's set several years ago but it is just tremendous in really highlighting what it means to be a go-getter. I listen to it on Audible and the audio book is like an hour long. Totally worth it! Totally, totally worth it! The second book that I'm going to pick is about an hour and a half long on Audible. I don't know how many pages it is because I didn't read it either. I just listened to it. It's called QBQ: The Question Behind the Question, and it talks about personal responsibility. It basically is training on how to ask the right questions, so instead of, "Why is this happening to me?" or, "Why does Alondo always push with broken tests?"
ALONDO:
[Laughs]
CHUCK:
Instead it's, "What can I do?" or "How can I fix?" or "How can I solve?" It's those kinds of questions and so it's "How can I?" And this really isn't a great QBQ either, asking "How can I help Alondo realize why the tests are important to have them pass?" but at the same time, at least then you are taking some responsibility to say, "How can I make the situation better? How can I solve the problem?" Maybe a better question is "How can I make test coverage or a not broken build more important?" and so then you start thinking about, “Well, I could put the CI results up somewhere where they're visible to the entire team, or I can do this or I can do that. I can set up a CI server,” so you're starting to take responsibility for what you can control to make things better. I can set up the CI machine to send out emails when somebody breaks the build. Just stuff like that, and so instead of being frustrated because somebody isn't participating in the way you want, you are taking responsibility and finding ways to make the situation better.
ALONDO:
That's actually excellent. I actually think that may be my afternoon listening [chuckles].
CHUCK:
So good! Another one that I liked I have to say this one is kind of really hokey. It's based on a metaphor and they took that metaphor a little too far, but I like the underlying premise and so I'm going to pick it anyway. It's called Rhinoceros Success; I don't remember who the author is for that either. It's about an hour long, or hour and a half long on Audible as well. I listened to all three of these in the same day. Anyway, I got them off of Dave Ramsey's required reading list for his employees, and I was blown away. Anyway, they take the metaphor a little bit too far, but the underlying premise is if you want something, that you should focus on it and charge it down like a rhino. And if you try and charge down too many things, you're not going to catch any of them, but if you focus and you charge with everything you have, then you should be able to get what you want. Again, the underlying principle was really, I think it's really important for people to understand, but like I said, you have to get over a little bit of the cheesy animal metaphor stuff. So I'm going to pick those books. Hopefully, people can go out and pick those up and make your situations better wherever you work.
ALONDO:
Awesome!
CHUCK:
And yeah, so those are my picks. Yeah, I don't think we have announcements so we'll just catch everybody next week.
[This episode is brought to you by Code School. Code School offers interactive online courses in Ruby, JavaScript, HTML, CSS and iOS. Their courses are fun and interesting and include exercises for the student. To level up your development skills, go to freelancersshow.com/codeschool]
[This episode is sponsored by MadGlory. You've been building software for a long time and sometimes it gets a little overwhelming. Work piles up, hiring sucks and it's hard to get projects out the door. Check out MadGlory. They're a small shop with experience shipping big products. They're smart, dedicated, will augment your team and work as hard as you do. Find them online at MadGlory.com or on Twitter @MadGlory.]
[Hosting and bandwidth provided by the Blue Box Group. Check them out at BlueBox.net.]
[Bandwidth for this segment is provided by CacheFly, the world’s fastest CDN. Deliver your content fast with CacheFly. Visit cachefly.com to learn more]
[Would you like to join the conversation with the iPhreaks and their guests? Want to support the show? We have a forum that allows you to join the conversation and support the show at the same time. You can sign up at iphreaksshow.com/forum]