From the blog.

Managing Digital Racket
The more I tune out, the less I miss it. But that has presented me with some complex choices for a nuanced approach to curb

Egos and Teamwork

490 Words. Plan about 3 minute(s) to read this.

My practice rack is staged and ready with the initial config for scenario 13, which I plan to do tomorrow. I am so tired right now. This week has just been a little much. Up at 3am a couple of days to support a fellow engineer who was making some changes. First time, it didn’t work out, since he was under a misconception of how PBR set ip next-hop recursive worked. Nothing like being on a conf call at 4am with a fellow engineer who’s halfway across the country, and then have to tell the poor guy that the command doesn’t do what he thinks it does. Especially when I knew he didn’t believe me. :) Oh, well. We redesigned the solution to the problem and implemented it a couple of days later after a larger group of engineers had a chance to beat it up on a whiteboard.

I don’t know about you, but I much prefer to have other people sanity check me. Am I taking the right approach to solving this problem? Does anyone see a flaw in my code? Is there a different way to do solve the issue that might scale better, make better sense, be easier to document, work consistently across multiple IOS platforms, survive a failure, eliminate SPOFs, etc.? I guess at heart, all network engineers are egocentric. If you’re good at your job, you take it personally when the network goes down, your solution doesn’t work, or things just don’t go right. It’s hard not to be like that. That’s especially true the bigger the network is that you’re working on, and the more your company matters in the grand scheme of the world.

To work as a network engineer as a member of a group that functions as a team…that’s a privilege. When everyone can put their egos aside and work together to come up with the best solution, not necessarily your solution, that’s a cool place to be. You get smarter that way. As soon as you realize that someone else might be able to fix the problem better than you, and you’re willing to learn from that person, you’re a better engineer. You’re more capable. You’re more valuable to your company and to your team. Knowing your limits isn’t an admission of failure. It’s really letting your team know that you can be trusted to say you don’t know when you don’t know. That you’re not going to get yourself, and consequently them, into such a nasty problem that there’s no easy way out, just because you’re too proud to admit you’re in over your head.

I haven’t worked with too many folks who could put their egos aside. It’s hard enough to put my own ego aside. But I can say that when I’ve done it, and when others have done the same, the resulting network has been something that, as a team, we’ve been proud of.

Ethan Banks writes & podcasts about IT, new media, and personal tech.
about | subscribe | @ecbanks