Well, could be. You do need to be self-driven, and also be able to see the bigger picture so you actually help your clients.
I think some distance is helpful, too. Some clients can be really dysfunctional in the sense that they will spend all day talking about things in meetings, and never do anything about it, probably because they're not comfortable bringing about the changes. That's why they hired you. You're the change agent.
But communication is important. There's no boss to set the expectations or clear up misunderstandings for you, you need to do that yourself, carefully. If you think you'll find it difficult to bother explaining things to people, then you probably need to contract on something where you can communicate through a version control system.
IMO, you have to be a bit... "spiky" ( as Eddie Izzard might say ) to work independently. It's worth being a bit paranoid about expectations. This means you have to manage expectations, design deliverables very carefully and perpetually review them.
And if you don't hand in progress reports, do them anyway and keep them for audit - you'll need them eventually whether there's any conflict or not.
It's nearly impossible to describe just how ambiguously most people communicate. I've been places where I was in-house and it got to the point where I simply made it a point to be as irritating and lawyerly as possible, not long before I left. It at least communicates "I'm not the one giving up here..."
Wow hard one to untangle and answer in a HN reply!
I sort of think... if you have to ask this here you might be in the wrong job? Was this a job that seemed like something else then became this? This sounds like a job for an experienced VP Engineering. It is a tough order. Wouldn't know how to do it myself. Lots of technical challenges, people challenges, growth challenges, and managing up and down.
The resistance to change is something you need to get to the bottom of. People are naturally resistant to change if they are comfortable, and we've all been through 'crappy' changes before at companies and been burned.
The solution might be to get them to state the problems and get them to suggest solutions. You are acting more like a facilitator than an architect or a boss. If one of them suggests using SVN or Git because they are pissed off their changes got lost last week, then it was their idea. No need to sell it.
This assumes the team feels like a unit. If the 3 are individualistic, then that should be sorted first. E.g. if Frank thinks it is a problem but no one else does, and they can't agree amongst themselves, then the idea is not sold yet.
Once you know more about what your team think the problems are and add in a pinch of your own intuitions you might be able to formulate confidently the problems, so you can manage their expectations.
It sounds like you have great technical ability and could easily solve these problems in the way your boss would like. So the problem is communication between you and your boss, that you aren't understanding exactly what he or she would like you to be doing.
Regardless of whose fault it is, it sounds like your work-communication skills could use improvement. And in my opinion, this is one of the easiest ways we can add value to our role as developers.
You can make it your business to ensure that all the details of each project are in shape and make sense before you start.
Because your boss said he doesn't like unconventional solutions, perhaps for the next few projects before you get too far along, make a technical plan and run it by him or her to get their input. If they protest, you can make a case for your way but if they would like you to use a different technology, well, they're the boss and you do it their way. Make it part of your job description to keep your boss informed of the major decisions you are making as you work on the project. If he knows about something, it means he has signed off on it and if the solution ends up being "too unconventional" it is no longer your fault.
Basically, you are learning how to make your boss happy with your work, as he is not. This will probably mean letting go of controlling how things get done and taking the initiative to communicate more, and that is something you are going to have to decide if you can be happy with.
If you need more autonomy you could find a small startup or founder who needs a technical partner; a job situation where you will have full say of how everything gets done. Maybe that is where you will be happiest. Regardless of where you end up, working on communication skills never hurts.
Isn’t it possible that you are not as ready as you think and that your leaders do not yet trust you to help them with more important stuff?
Could you use this opportunity to improve their process or even “teach” the company and team mates a few things here and there?
How about you show some leadership and drive them to where you think the team/company should go?
As I accumulated experience and worked with hundreds of people I found that people are most likely to complain and want things to be different but very rarely they want to change themselves or lead the change. The ones who do are the ones who succeed.
It sounds as if your understanding of the problems differs from those of your new colleagues; have you considered whether your resistance to the changes is properly calibrated against the needs of the business?
I was leading the large project, it was a core system for a financial organization.
Because of a fast pace and because of the fast growth and because of the unexperienced management, it was impossible to quickly train and delegate things to the appropriate people.
I was often getting a call from the devs, asking for help, and I was like “it works so and so, check the X file and find the Y method, that’s where you should apply changes. When you do that don’t forget to do Z.”
I was also getting calls from the top or middle level management. They were asking me things about the product specifications, marketing metrics, etc…
Literally everything “that guy” that knew everything.
The pace didn’t slow down, the opposite, company wanted to grow like crazy. I couldn’t keep up with everything. I remember I had a honeymoon in Thailand and I was literally hanging on a phone to dictate people how things worked and what they should have to do.
Things ended up miserably. The new CEO came and we agreed that I needed help with the delegation: I needed suitable people on-board and time to teach them. The process started. But it was going slow. We still had a fast pace of growth and I was trying to hire and delegate along the way.
After some time, I was accused to be a “ corporate parasite”, keeping all the knowledge to myself to be indispensable and irreplaceable. I left the company soon. Did my best to transfer the knowledge before that.
In the end, it’s been one of the best experiences I had. I grew professionally and mentally, nowadays I easily spot the problems while they become big, know who is who in a glance and so on… I learned a lot along the way.
Several advices someone might find useful:
1) If you cant align with the decision makers you either have to get used to it or move on. Mostly you have no control on the other peoples’ thoughts. If it’s broken, it’s broken. Period. Don’t prolong your decision.
2) Always under-commit and sometimes try to over-deliver. Depended on the quality of your management or organization you might want to over over-deliver and be respected. If you’re in a situation like this then good for you.
3) If you want to grow your organization and the team, you must learn how to delegate tasks and get deliverables, without micro-managing people.
4) In the end, its more about people and less about technologies. Your job is to understand, manage and delight people and solve all the problems along the way.
Right, I agree with you that I am not filling the shoes of what I should be doing, and that is one of the reasons I'm not happy here, but that's not due to lack of awareness or effort on my part. I have never had issues communicating to non-technical people before. My previous managers have always commended me on my communication skills. In the past I consistently raised issues and potential areas of for improvement, explained the significance, and came to agreements with the product and project managers on a reasonable balance between continually improving our systems, maintenance, and adding new features. There is also another huge factor that complicates things, that is out of my control -- our systems are tied to a partner company and to a large extent they have determined our technology because our apps run in their servers, on their datacenter. So we've been stuck on Windows 2000, SQL Server 2000, running COM+ stuff, because those guys never upgrade their crap.
However, some projects to improve systems and to finally start looking at decoupling from the external partner are FINALLY showing up on the roadmap for 2013. I spent all of 2012 on a brand new project where I enforced my vision of how things should work (totally modern tech stack, automated builds, cloud deployments, etc). That project was a big success.
So if I were to stay one of the things I want to know is how I can convince my manager to get out of the way more, and let me handle a bigger role in planning and executing the projects. Because even though the projects are coming up, he is already starting to try to "mentor" the jr dev's by trying to get them to "own" specific new projects and feature areas for things that we'll do in 2013. I strongly disagree with this approach; I want team ownership, but with his hub and spoke approach (my +1 being the hub) to managing, there is no real development team. The Jr. dev's practically never increase their skills because they spend so much time on legacy code and tedious operational stuff that can be handled by interns (i've recommended this before, buy my manager doesn't agree).
Your point is well taken though, and it's something I've been thinking about. I would welcome any advice on how to arrange a better environment for myself at the company, that would allow me more autonomy in leading the developers. How do other lead developers at small startups handle this kind of situation? Who assigns tasks directly to developers? My manager micro-manages, and assigns individual tasks to individual developers. I know that if I got to lead the team myself I'd have been able to incrementally upgrade parts of the system to free up the Jr. developers' time, and by today they'd have a lot more free time to work on even more new features. How do I discuss this kind of thing with my manager without offending his clear need to maintain strong control over the Jr. developers?
Take a step back, breathe and relax. Set it in your mind that the company you're working for has been running with or without you. Take the burden off your shoulders and clear your head. After getting some peace in your mind, you can take action:
The first thing you have to do is to tell your client/boss, without all the computer-techy talk, the situation you're in and how it's going to actually affect them. Clients get pissed off not because things don't "work" or the user experience is "broken". Clients get pissed off because they expected them to "work" and the experience is "nice". Clients have expectations, and most of the time (for non-techie clients), they have unrealistic expectations. Set their expectation and make them understand the ramifications of having ONE guy working on such a massive undertaking under your specific circumstances.
After you do this you'll find that it's much easier to breathe in and actually work. In goodwill, they will set aside time and plan things to actually help you, because they know in the end it will help them.
Next steps are usual dev protocols:
1. Get it in version control with a dead simple bug/issue tracking system.
2. Always write good commit comments.
3. As for documentation, do it incrementally. Write small bits each time you work with the app, or each time you deal with your build/deployment process. It will compile into good documentation later on. If possible get your documentation into version control as well.
I highly recommend that you do these things and produce a consistent flow of routines in your work before getting other people to help code with you. It doesn't help when you have another person sitting around burning precious time figuring out things as he goes along the way. On-boarding them without those 3 things listed will be hard, and it will put off a good amount of time from things that actually need attention.
If you're implementing Agile on a personal level, make sure other people are on-boarded with it.
You'll find that adding people will be much easier. The cost of logistics regarding adding additional team members rises higher than expected if the development workflow and environment isn't established. You'll burn time on-boarding good developers, you'll burn even more time on-boarding mediocre developers (I've personally experienced this in my previous work).
While changing requirements are outside of your control, clearly the consequences affect you, however unfairly. It's a skill to predict what might change and which parts of the project could end up being wasted time, and you will develop it with experience. I think being in continuing regular communication with your manager and team members as others are suggesting is also a good idea and partially for indirect reasons, because you might pick up on some clues of what these things outside your control may end up affecting how your performance is perceived.
My basic role is analysis and database marketing for a non-profit foundation. I was hired into a new position for them a little over three years ago into a role that was an amalgamation of a bunch of roles from people who had left. They unified these roles into a single role, and split the unrelated work between other people in the organization.
I set the strategy for all of our mailings, run the data, and then analyze the performance. We have 800,000 constituents, and send about 500,000 appeal letters each year, as well as countless emails and other pieces of mail. I've managed to decrease our cost to raise a dollar from about 22 cents to about 6 cents, while improving the overall quality of our appeals, which I'm pretty proud of.
We are a really small organization (<50 employees), so I end up doing a really wide variety of tasks. We have a lot of challenges that larger organizations wouldn't have because of our limited manpower.
Since nobody had really taken a holistic look at their data before me, I spent the first year cleaning up all of their existing data and automating almost every processes I could get my hands on. I used to spend 3 weeks of every month running recurring processes, and I cut that down to about 15 minutes a week.
After that first year my manager left. At this time the Director asked me to come work directly under him because he felt that none of the other managers understood my role well enough to manage me. This allowed me to focus more on the analysis and marketing side of my role.
As time has gone on I've been asked to create more processes for speeding up other people's work. I'm not an application designer, and I recognize that the processes I'm creating are pretty fragile. This wasn't a problem when I was automating my own processes, because if they broke I could fix them. Now there are a bunch of people using processes that only I can fix, which makes it very hard to take a vacation or a sick day. This causes me a lot of stress, which is a key reason why my walks have been trending longer.
I'm basically somewhere in the middle of the graph from the XKCD comic Automation[1]. I'm starting to look for a new job before fixing broken automation steals the time I need to make a resume (or do the part of my job I really enjoy).
So long story short, I basically do anything involving the data or programming for a small-to-mid-size non-profit organization.
If you don't manage them directly that sounds like you don't have authority.
Without the authority to make changes you this will be very hard to do, given the scope of changes required. Soft skills and influence works up to a point but given your remarks about resistance to change this is a big challenge.
You need to ask for the proper remit and authority, or decline and move onto another project or job.
Awesome, you've identified one of your biggest weaknesses. Also, you've gotten better at it recently.
It seems to me like you need some time to work on that. For me, learning to say "no" and establishing my authority to clients regarding the direction of a project was HARD. It took me at least 2 years from the first time I noticed to get to a point that I could run a project pretty damn smoothly.
Also, I suggest you take some time off. Like, a day or two just hiking / playing around / having sex / whatever. Just go outside and so something away from computers and away from your customer's emails. Then come back with an objective mission of taking care of shit in a prioritized way.
Thats my last advice : write down what needs to be accomplished and check it off. Do it each week or monthly at first and eventually you'll be banging them out daily and feeling stoked.
Thanks for your time and advice. I've came to the same conclusions as yourself already, but It's good to know that someone with more experience then me echo's the same thoughts. The main reason I brought him on was to be the motivator, ironically. Although I lead the product vision, as well as doing the actual front-end grunt work, I wanted to hand-off the motivation role so I could concentrate on other things. As it stands now, not am I only trying to keep myself going, I'm trying to keep him going as well.. and it's already starting to mentally drain me. Thanks again.
Ah ok, sorry to hear that. With such a small development team, it sounds like it could be hard to move into management. However, this should also present opportunities: if you see something that needs to be done and no one's dealing with it, do it yourself, accept the responsibility and try and make sure some one notices that you've gone to that effort (or ideally, point out the fact that you're going to do this to whoever you report to).
I attempted to make this change a few years back, and failed miserably.
What went wrong? For me, personally, the problem was still having too many developer duties. I had a full schedule of management duties to attend to, and a full schedule of development duties to attend to. I quickly began to burn out, and did a poor job on both. Although I excelled at some of my management duties, others were critically neglected due to lack of time. Specifically, at the manager level inter-team communication is important and I did a shitty job of it.
In hindsight, I should have dropped my developer duties completely. I didn't because my team didn't have the employee resources to meet its objectives. But attempting to take on critical-path development duties in order to fix the problem was the wrong thing to do. I did me no favours, nor did it help the company. Maybe I did it because I was more comfortable doing development than with the inter-team communications duties I was neglecting. In any case, we would all have been better off if I had spent more time paying attention to my team's place in the rest of the company, and simply pushed back on schedule and resources.
Sometimes things are messy in the early days. Are things getting out of control at this particular company? Hard to say. If you want to push for change be polite and persistent and focus on one or two key changes to the workflow. Not everything at once. Or if you can’t stand working this way you could jump to a more mature startup.
If you're not familiar with the system, why are you insistent on changing it? And since you're new to the team, what's the rush to tell everyone their work is poor? What would be your reaction if you were in their place? How do you think your approach will play out in the long term?
At a startup I worked at briefly (~4 weeks), engineers were constantly being asked to do ad-hoc pieces of work from people all over the business. A product manager who started around the same time as me tried to introduce a lightweight triage system for his team by which inbound requests would go via him. He was immediately taken to task by the CTO who told him to stop rocking the boat and not to introduce any other changes until the new VP of product joined in a few months.
Arguably he tried to change too much too fast, but anyway, there's a reason I only lasted 4 weeks.
It is possible that you are not being intentionally sidelined. This has happened to me, where a company hired a new PM to help us scale, but just took over the parts of my job that I most loved, leaving me with just the drudge work.
I was livid. “We have a new guy... who doesn’t understand the product or our customers or our process... and I am supposed to answer to HIM now?”
Some advice I wish I could go back 10 years and give myself:
1. “Own what you own” which is a variation of “choose which hill to die on”. If you feel like something is “yours” you will resent people coming in and fucking it up. If you conceptualize something as “theirs” you can feel good doing your best to make it better. Being a humble servant can feel bad, but it feels better than being fired for having angry outbursts (trust me on this one).
2. Understand your feelings well enough to talk about them. That might involve talk therapy. Modern CBT is really great.
3. Remember that anything you love can break your heart. And that is OK. Better than not loving what you do. Maybe it is time for the relationship to end? Maybe you can salvage it?
4. Think and talk in terms of both work/life balance and work-life balance. If having a diverse set of things to do at work is important to you (it is to me, but not everyone) tell the company this. Some people love to be heads down coders in one layer. Other people need to work across more layers. Some people like to do PM or architecture work in addition to coding. Your managers won’t know what you need if you don’t tell them, and you can’t tell them if you don’t understand it yourself. (See #2).
I think some distance is helpful, too. Some clients can be really dysfunctional in the sense that they will spend all day talking about things in meetings, and never do anything about it, probably because they're not comfortable bringing about the changes. That's why they hired you. You're the change agent.
But communication is important. There's no boss to set the expectations or clear up misunderstandings for you, you need to do that yourself, carefully. If you think you'll find it difficult to bother explaining things to people, then you probably need to contract on something where you can communicate through a version control system.
reply